Would this architecture work with Cloudflare Workers?

[Eduard-Hasa]

Hey @Sairyss

I would really love your take on how you would approach building a fairly complex backend today if you prioritized speed of development for something like a MVP that you want to be able to handle fairly complex business logic.

What are your thoughts on
cloudflare workers, durable objects, their new rpc bindings allowing direct function like calls between workers and durable objects, their new d1 sql database, could they be possible to build reliable systems that can handle complex business logic? I fear I'll go down that rabbit hole only to waste more time trying to fit complex business logic into something that isn't made for it.

[Sairyss]

First of all, ask yourself what problem you want to solve with cloudflare workers. Do you currently have any problems that are not solvable with the current architecture?

Are you experiencing slow development speed with the current architecture? Maybe you over-complicated some parts and should simplify it, you usually don't need complex architectures while building MVPs especially as a single person. MVP is usually a code that you may throw away in a couple of years, so don't worry too much about making a perfect architecture.

I personally would not move to cloudflare workers or any other cloud functions, it's mostly marketing and has it's own flaws, like vendor lock-in, issues with library support, extra complexity compared to a simple monolith, etc. Plain monolithic app is the simplest and cheapest approach, for MVP you don't even need a cloud, any VPS server would be enough.

[Eduard-Hasa]

This all makes total sense. I was just wondering what the different use cases are for domain-driven-hexagon repo vs fullstack-starter-template repo. For a one man team trying to move really fast with getting a startup full stack app going which one would you recommend starting with?

[Sairyss]

Depends on your needs.

• domain-driven-hexagon - this one is intended for apps that have a lot of business logic.
• fullstack-starter-template - this one is for simpler APIs (if you want a monorepo and like tRPC and other libraries used there). tRPC lets you develop features faster, but it has it's own downsides. I would recommend to do your own research on it and decide weather you want to use it or not. If not, replace it with a regular REST API.

Both repos are not intended to use "as is", they serve mostly as an example for you to modify or build your own that matches your own needs and preferences.
I would start with any that you like more, then modify it to your needs as you progress.

[Eduard-Hasa]

Depends on your needs.

• domain-driven-hexagon - this one is intended for apps that have a lot of business logic.

• fullstack-starter-template - this one is for simpler APIs (if you want a monorepo and like tRPC and other libraries used there). tRPC lets you develop features faster, but it has it's own downsides. I would recommend to do your own research on it and decide weather you want to use it or not. If not, replace it with a regular REST API.

Both repos are not intended to use "as is", they serve mostly as an example for you to modify or build your own that matches your own needs and preferences.

I would start with any that you like more, then modify it to your needs as you progress.

Fullstack-starter-template is really appealing for early stages. Feels like I would fly through building a backend with it. Would it be feasible to take the approach of starting with that and when business logic starts getting really complex rebuild with domain-driven-hexagon practices? Making sense to me because I'll have a really good idea by then on how complex my business logic will get and what my requirements will be. Right now i have a decent idea but it seems very possible with a simple service to handle all the business logic

[Sairyss]

It's pretty common practice to start with something simple to progress faster. When you are starting not all requirements and corner cases are clear, so the first step is usually to build something fast that may be messy, but does the job. Then after some time you will understand your needs better and can do a rewrite with a better architecture if the need arises. That's what MVP is basically, something that you can build fast then potentially throw away and rebuild.

Before starting with fullstack-starter-template I would recommend to do a research on the libraries that are used there. I created that repo 1+ year ago, not sure if all libraries there are still relevant/maintained (knowing JavaScript ecosystem lol). If you are satisfied then good luck, hope to hear about your startup in the future :)