re: Is The Web Forcing Us to Split Applications the Wrong Way? VIEW POST

TOP OF THREAD FULL DISCUSSION
re: This is actually something I've thought about a lot, it sounds great in theory to split by app domain instead of client/server, but the question I ...
 

I actually think making your business logic one sharable unit makes your app more portable. The UI just calls into that shared logic. Need to port it to a new platform? Just write a new interface layer.

Have a look at the ports and adapters architecture, also known as hexagonal architecture. All platform-specific things would just be adapters.

 

This is something that I've been trying to do with my apps. The business logic and models are written in a language that can be moved between platforms with little to no changes (I'm currently using C#). Then, I just write up a front-end that follows the established rules of the platform while providing the same functionality across the board.

I haven't deployed it yet, but it's made "porting" so much easier.

 

Wow. I didn't have time to take a detailed look at the whole article yet but just looking at the first graphic gives me a good feeling about it. I've actually kind of thought about structuring apps similar to that before but I never knew there was a whole pattern for it already out there. Amazing!

So in that case would you still have a small client/server split but just build a backend 'port' that kind of understands more about what the frontend needs? So if you were serving say a react app on the front end it could access a specific route on the server layer that would return information more curated towards that specific interface, instead of just generic JSON objects?

code of conduct - report abuse