API driven
Opened this issue · 9 comments
While in the early stages of development i would strongly consider moving to be api driven so you decouple the frontend and backend allowing for greater scalability and modularity.
If you need help with this at all, let me know and i will be glad to assist wherever i can.
If you opened an API I could develop an iPhone app.
Yea, lets go ahead and split everything out into 45 Go services, with Docker image deploy pipeline, React, Fluxed, front end Gulping the DOM, with asset deployed Relay mapping of Webpacked dependencies NPM module plugin GraphQL so the CLR main execution zone will fit in and keep the html object state hard and fast.
Or you know we could just do respond_to :json
@drewhamlett A simple API to keep the frontend and backend separate and allow for easy expansion was more what i was going for.
If you will open API I could develop android app.
couple separate threads here:
-
Creating a public API
-
possibly redo frontend in a technology and consume our own api, instead of standard rails generated pages
Both great discussions to have and worth considering.
In terms with decoupling I think it would be a great idea as it would allow for rapid UI prototyping, greater test coverage, and a consistent backend to consume. Not only that but it does naturally lead to a public API with the option of targeting multiple platforms.
Since it's a content site that's literally a list of links, seems to me to make more sense to just spit out html views. Why bring in flavor of the month client side mvc to do that. It' easy to spit out json views also for other use cases.
@drewhamlett Because it allows for a unified experience across the board where all clients work in the exact same manner from a single codebase.
@nblackburn It never works like that in the real world anyway. Plus in Rails, json is just another view. You don't have to choose one or the other.