My day job is designing and developing websites, but in my off time, I like to build all kinds of things, including Ruby gems, iPhone apps, and Alexa skills.
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 always come back to is... would it ruin the portability of my app?
I feel like in today's world (and especially in tomorrows world when internet is practically omnipresent), users expect apps and services to be available wherever they are, whether they're on a phone, tablet, or computer, whether they're at home, in their car, or at work, whether they're talking to Alexa, Google, or Siri, and eventually, whether they're in the physical world, the augmented world, or the virtual world.
With so many different interfaces out there I feel like I should be designing apps to be as adaptable as possible to new devices and operating systems, and I wonder if coupling the backend with the front end too tightly would just end up making life harder in the long run.
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.
My day job is designing and developing websites, but in my off time, I like to build all kinds of things, including Ruby gems, iPhone apps, and Alexa skills.
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?
I'm a father of four. I started out as a self-taught programmer, completed a B.S. in Computer Science and am currently employed full-time since 1998.
I also own a small mobile software company.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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 always come back to is... would it ruin the portability of my app?
I feel like in today's world (and especially in tomorrows world when internet is practically omnipresent), users expect apps and services to be available wherever they are, whether they're on a phone, tablet, or computer, whether they're at home, in their car, or at work, whether they're talking to Alexa, Google, or Siri, and eventually, whether they're in the physical world, the augmented world, or the virtual world.
With so many different interfaces out there I feel like I should be designing apps to be as adaptable as possible to new devices and operating systems, and I wonder if coupling the backend with the front end too tightly would just end up making life harder in the long run.
What are your thoughts on that?
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.
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?
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.