I’m building ZenStack: a full-stack development toolkit on top of Pirsma ORM that simplifies the development of a web app's backend. It uses the s...
For further actions, you may consider blocking this person and/or reporting abuse
Code generation is really good approach if the generated code looks like the written one, and can be extended.
I'm gathering such solutions under GeneratedCode.io
I can add ZenStack there as well, just provide me with a pitch line
Thanks for the recognition. Here is the pitch line follows existing style of GeneratedCode.io:
Turn Your Prisma Schema into a Secure Fullstack App in Minutes
done is updated
There are so much different user case for code generation, some are, some are not. I actually started my first internship by writing a code generator. The goal was to automate all the copy pasted layer based on the entity definition. While i did enjoy that task, the resulting architecture mean that you have a whole lot of (automatically) copy pasted code and add I believe most dev agree, code duplication is usually a code smell. We could argue that if it's generated, then you don't really have to maintain it, but i would if as a dev you have to open those file, debug through then, then it does impact the code/architecture quality. In those case, they're often better code pattern and architecture to reach your goal.
On the other side, any kickoff code generation is good imo, like yeoman or maven archetype. Those tool will generate all the boilers plate code to start your project but then it becomes your code and you clean it up as a first step and never use the generator again.
On a similar pattern of generate once, Django migration are also a good example. It take a few seconds to generate the db migration script, they are easy to review and customize but it become your own code afterwards. Bonus point, once deployed, you never go back modifying it in this case.
Then there is what is call "background code generator" haven't seen a lot of them, it's code that get generated but you will never have to see it or debug through it, the only example that come to mind is Project Lombok even if we might not consider it purely a code generator that would also be fine to me as it simplify boiler plate code that really no one cares about.
I'm the end, the most important question to me is, after the code is generated, what will be the cost to me maintaining that code. Of the answer is more than writing it myself or using some other pattern, then it's a no go. The reason is simple, as a dev, we will spend way more time maintaining every single line of code than initially writing them.
There is also another factor to take into consideration, what feature your language allow. Java is really poor in dynamically creating interface or object attribute which make it more likely to see a benefit from code generation. In the other side, python or JavaScript can create new interface and attribute on the fly and thus are way less likely to need code generation since the language is flexible enough too write generic code that since the same problem
It really depends hugely on the use-case.
Generated code is great for APIs: Making sure that at least one end is generated from a specification makes communication a lot easier.
Generated code is also great for repetitive boilerplate. We wrote a simple PHPDoc-based code generator to expand DTOs and their Builders with optional aspects - child models that may or may not exist on the instance, and thus implement a trait and interface to type check against, for each combination of child models. So you'd have DTO A with aspects B and C, and there'd be resulting A, A+B, A+C, A+B+C DTOs. A beautiful idea for PHP7.4, making it clear on the class which features it supports. But horribly annoying to implement manually when there's six or seven aspects.
But there are so many use cases where code generation is used that are only really worth it if there's an out-of-the-box solution (e.g. project creation or migrations)
It's hard to argue with processes which reduce the amount of time you spend doing a task.
The only situation where I'd likely criticize code generation is if the output is obfuscated/minified and I have to debug that file, but typically processes can be tweaked to produce the desired result.
@theaccordance obfuscated output is not of much help, that is basically a low code tool that allows export.
generated code(hopefully becomes a concept on it's own) means the output looks similar to the one you would write. That way one can extend and change anything - the only way to achieve long run productivity gain.I am using Vely framework, which generates C code on the back end. It is really sophisticated generator though, to the tune of being a full blown declarative language. It also integrates well with C which makes it fully customizable. I think generators are great if done right. After all C++ was generated C for quite awhile.
I think ORM or SQL databases, one of them is anti-pattern. You usually don't need an ORM to work with document databases because the data access model matches programming model well. SQL's way of modeling nesting is bizarre, and ORM is a fix.
Сongratulations 🥳! Your article hit the top posts for the week - dev.to/fruntend/top-10-posts-for-f...
Keep it up 👍
Thanks again! I will keep trying.
One “gotcha” with generating your frontend graphql api code for a prisma backend is that you really don’t want to expose the full capability of prisma to query your data to the public internet, for obvious reasons, and if one is just following tutorials and copying boilerplate that’s what you often end up with.
This isn’t the fault of code generation itself, of course.
I believe this post is a response to my 'why Prisma code generation sucks?' So here we go again.
To understand why Prisma code generation is unfavorable compared to common cases of code generation, I think the best analogy is: 'If giving birth is more painful than getting kicked in the groin, why don't men ask for a second kick, but women do ask for a second child?'"
Take the example of transpiling TypeScript to JavaScript. We gain type safety without changing how the runtime works, which is a huge benefit. Additionally, we transpile modern JavaScript to ES5 so that the majority of browsers can run our code without problems. We also transpile front-end code like Svelte, JSX, and Vue template syntax because these front-end frameworks allow us to write more maintainable code.
The hassles of code generation like these are bearable because they provide us with great benefits. With a library like Drizzle and Kysely, we can declare schemas using TypeScript without the need to learn an extra language.
However, the value of Prisma code generation is simply not as great compared to other common cases of code generation.
Not all code generation provides equal value; some are simply worse/better. This is analogous to why women are willing to give birth to a second child - because the child itself holds inherent value.
Meanwhile, Prisma code generation is like getting kicked in the groin for nothing but pain: the pain of constantly regenerating code, and the pain of learning a low-reusability language.
We have the choice not to suffer the pain, not to get kicked, and not to invite more problems to solve.
Thanks for sharing different views and also for the elaboration on Transpiing. I guess Compiling is just a more general and recognized term that could include Transpiing for most cases, which you can see in the official doc of Typescript and Svelte.
I think quite a few languages use C as compilation target?