NextJS + Prisma monolith

October was quite busy month in terms of travel and work related. Wanted to progress faster ongoing projects but i did not stop discovering new potentials.

I have worked and still working with NextJS but not as monolith, more or less than a base for SPA apps in a monorepo. On the other hand, i am building the second version of eDominations, so called eDomLegacy as SPA with api and for live communications socket service.

Let's talk through first what are the pros and cons building SPA and api service separately.

SPA + Api service + Socket service

Cons

• You have 3 different repository and applications to develop and maintain in your hands. In my case 2 of them are in javascript/typescript (SPA + socket) and 1 in other language. This creates gap for typing same things all over again on 2 different languages.
• Hard to maintain all the packages. Too many applications to deploy.
• Relatively slower development due to duplications ( due to differences in languages used ) and thinking a lot on how to share all the work as good as possible.

Pros

• Business logic is/has never been exposed. I have simply published api and socket service in staging server so that SPA can be developed by literally anyone. All they had to do is to change their .env variables to staging server and there you go.
• So much easier deployment. If you have only design/code update changes, you are not bothered yourself deploying backend code or socket service.
• Easier code management and less complexity. Considering each service of the ecosystem has its own concerns, delivering this knowledge to a newcomer or working with it gets pretty easy.

NextJS with prisma

As you may know, prisma is a great ORM that resolves many problems when dealing with data. Almost every reliable framework has kinda solutions either built-in or provided as service. I had tables with their columns generated and its quite big. Creating models and types with prisma for those was just a single line of code. This genuinely mesmerized me. No kidding, that's normally a lot of work. I have got all the types ( typescript ) and model schemas. very high type safety while querying anything. This was a win-win situation that may benefit the ones that thinking on migrating.

Okay, i will keep it short.

Cons

• There are not many features in nextJS framework wise ( yet ).
• Writing queries with prisma is quite different, migrating may create an issue where you may need to rewrite everything.
• Monolith? this may not be a cons for some but might be for some others.
• Javascript does not know about types like u32int or sql types such as bigint. Javascript by design stores all numbers as double precision floating point numbers. So you got to hack these types a little.
• Deployment. Yeah all right, we may not count this as cons yet changing red button will require deployment of entire application.

Pros

• Single language ( typescript )
• Prisma is a great tool to generate models and types.
• Shared types, code across entire project.
• Monolith? this may not be a cons for some but might be for some others.
• Deployment. Single application to concern about. Vercel option and all that benefits comes with it.

I believe choosing the right ecosystem matters a lot, considering migrating at some point is almost impossible. Simply imagine that you have written Java code for years now needs to be rewritten in typescript. Well, that might end up bankruptcy in business :)

I guess this was short and fine this time. I hope, I plant the seeds of thought into your minds to fiddle with most likely next hype train in javascript/typescript world.