Topics
Anahita Project's Topics
Separating Anahita API and Client side
Here is another idea. Developing the React client side as a vendor in a separate repository. Reducing the existing php codebase to APIs only. There is no need to bake the react javascript app into Anahita's architecture. This way people can choose to use a React or Vue client side or no client side at all by simply changing the composer.json file.
Apps primarily extend Anahita's API. They may include a client side javascript app library in assets/js/react or assets/js/vue. Once an app is installed, it's javascript library is merged statically or dynamically with the base javascript app.
We will be distributing the anahita-react client side, but 3rd party developers can build alternative client side technologies in whatever javascript framework they are comfortable with. The anahita-react repository will contain a php wrapper that contains the react app.
Any thoughts?
Nick Swinford
I've been thinking about using Anahita just as a REST API and creating the entire front end with #emberjs. That way the front-end can be delivered easily with something like Amazon S3.
Rastin Mehr
Ideally we would want an API only microservices architecture on the server side and client side mobile or javascript apps. I looked into a number of rails, python, and php applications. They are all mixing React with their php files. I think client side apps deserve to be treated as independent projects.
Umesh
Rastin Mehr
James Imani
For their backend they use ABAP and for their frontend it's SAPUI5 which provides me hundreds of JS functions to execute backend procedures. I can recall them easily within my app development containing their own views (HTML, XML or JS based)/controllers/models.
Rastin Mehr
Rastin Mehr