In the beginning, there were only full-stack developers. We implemented everything in the backend with some PHP or Ruby On Rails and then, with a b...
For further actions, you may consider blocking this person and/or reporting abuse
I've some doubts about this ΒΏarchitecture framework?
So you are unifying layers instead on separating them, this could be fine and was the only way to work with software for years, also called monolithic architecture. This is good for little projects but when you need high coverage you need to abstract the layers to maintain each instead on touching it all at the same time (scalability). This, at first sight and reading it superficially and fast, seems a monolith using APIs for the data transfer, isn't it?
What does it adds over the table in comparison with services, microservices or monolithic architectures?
thanks
I think you didn't get the point. Liaison removes the need to build a web API but doesn't enforce any type of architecture. You can break down your application into as many layers as you want and you can run your components in multiple execution environments.
Does It removes the need to build a web API by using graphQL so translating the logic into the front?
GraphQL is a web API, so in terms of layers, it doesn't remove anything. You still have to build an API server and an API client.
Yup so, if not a monolithic architecture and not API driven, how does it transport data? Thats what I was asking for. The benefits on using this are not clear to me as you can phisically or logically separate or join some layers but at the end you'll need to code them on a manner or another anyway. Doesn't it?
Obviously, you need to code your business logic, but the communication between the layers is handled for you by Liaison. To better understand how it works, please have a look at the documentation.
Thanks! I understand what do you mean with the extra information on the docs, I'll take a try when possible, at this point I'm more used to react, preact, svelte... but it could be fine to test. I've no much time those days but I'll let it pinned :)
Have you build some Apps with that?
Liaison provides a React integration.
Here are some examples of simple apps:
I build real apps for a customer, but they are not publicly available.
Understandable, thanks :)
This is an antipattern.
Could you expand, please?
TLDR: Your creating your own problems and then develop solutions to solve them.
The "Liaison stack" is actually the default stack for any small company and if you are running a larger application you probably are seperating your services by default at least for the reason because they are running in the cloud and therefore are seperated by nature.
If you have not reached the scale which requires to split your architecture in such a manner you are fine with running a backend server with database and whatnot serving your frontend client which communicates with the backend api (monolithic).
"Cross-Layer Inheritance" is done by extracting shared code into packages (typescript with interfaces is helpful) and install them as dependencies which is one of the reasons why people are so hyped about node in the first place (I can use JavaScript on Frontend and Backend).
You dont want any of your business logic on the client anyway.
Given the examples you gave and the requirement to have a SPA I can just implement it easily with plain PHP, JavaScript and HTML without having expertise knowledge of it precompiling anything etc..
Sometimes developing is just tedious and you have to write stuff bc of reasons.
Thanks for your detailed answer but I'm afraid you didn't get the point of Liaison.
Obviously, if you can implement everything in the backend in PHP, you don't need Liaison.
But if you have a user interface with some rich user interactions, then you need to manage the user interface in the frontend and you need to build a web API to communicate with the backend.
Liaison removes the need to build a web API but doesn't enforce any type of architecture. You can break down your application into as many layers as you want and you can run your components in multiple execution environments.
There is a good reason why we're separating our front-end and our back-end - in this way front-end part doesn't make any assumptions about the back-end, which isn't the case with your framework.
I see you centered all your design around components, but how does it work in the practice if I want to add custom logic? Are components actually used as services? What if, for example, I had a component which depends on another component, for example I had
Ordercomponent which needsUsercomponent for fetching some information?This is a nice experiment but I can't honestly see using it except for some small CRUD prototypes.
The frontend and the backend are physically separated but from the point of view of the developer, it's like they are a single thing because the frontend can "inherit" some methods from the backend and call them remotely.
I don't get when you say that a frontend shouldn't make any assumption about the backend. The frontend should at least know what is exposed by the backend and how to call it. Conceptually, calling a REST API or a method is no different.
A component is just a class and you are free to compose multiple components in the same way you would compose multiple classes.
Please check out this example for something that goes beyond a small CRUD prototype.
Please people remind what's wrong with using rails 2020?
Rails is great to build websites but in my opinion, the single-page application model is a better fit to build web apps.
Your idea of full-stack simplification is very similar to my point of view. I'm also working on an object-oriented framework, which has very similar goals and principles, but uses completely different set of tools :-) It's based on the Kotlin language and you can read more about it in my other posts.
Even if we compete in the some area of web development, I wish you good luck with your project :-)
Thanks, Robert! Good luck with your project too! :-)
Can you explain me why meteor isn't suited for today's environment?
For example, it seems that Meteor does not fit well with a serverless deployment.
And that makes it directly "not suited for today's environment"? A bit extreme.
Does serverless support websockets at all? I guess long running connections won't be nice for the bill?
AWS API Gateway supports WebSockets that are managed by Lambda functions in a cost-effective way: aws.amazon.com/blogs/compute/annou...
This was reallly helpful.
Looking forward to more blogs from you!!
What about blazor? C# in backend and front-end seems like a simpler way of doing things.
To my knowledge, Blazor does not flatten the stack.