search

OpenHunting / openhunt

discover new products, give feedback, help each other
MIT License
412 stars 49 forks source link

API driven #23

Open nblackburn opened 8 years ago

nblackburn commented 8 years ago

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.

craigpearce5 commented 8 years ago

If you opened an API I could develop an iPhone app.

drewhamlett commented 8 years ago

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

nblackburn commented 8 years ago

@drewhamlett A simple API to keep the frontend and backend separate and allow for easy expansion was more what i was going for.

mecid commented 8 years ago

If you will open API I could develop android app.

jacquescrocker commented 8 years ago

couple separate threads here:

1) Creating a public API

2) 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.

tomchinery commented 8 years ago

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.

drewhamlett commented 8 years ago

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.

nblackburn commented 8 years ago

@drewhamlett Because it allows for a unified experience across the board where all clients work in the exact same manner from a single codebase.

drewhamlett commented 8 years ago

@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.