Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TasteServer? #9

Open
mrpotes opened this issue Jan 31, 2014 · 7 comments
Open

TasteServer? #9

mrpotes opened this issue Jan 31, 2014 · 7 comments

Comments

@mrpotes
Copy link

mrpotes commented Jan 31, 2014

I was reading the history around tastejs/TasteApp#1, tastejs/TasteApp#2 and tastejs/TasteApp#4. It seems to me that not only would it be good to create a multiple-implementation front end app such as is being discussed there, but what about a multiple-implementation back-end as well? If we had a spec for an API that the front end app was going to use, we could implement that for multiple languages, such as .NET, Java+various libraries, node, Scala, etc - using Heroku/GAE/Azure for deployment.

I'm happy to invest some time in doing this, but it may influence the decision about what spec to use for TasteApp (from the suggestions put by @paulmillr and @jeremychone), which is still undecided.

What do people think?

@sindresorhus
Copy link
Member

@mrpotes that's what https://github.com/tastejs/TasteStack was supposed to do for todo apps, but @addyosmani and I never managed to find time for it. We'll still be interested to see something happening there for sure.

@paulmillr
Copy link

@mrpotes I totally support this idea. Ost.io has an actual API specification so you can make a second backend app in .net even today.

@mrpotes
Copy link
Author

mrpotes commented Jan 31, 2014

@paulmillr We could use the ost.io API - it would probably need a bit more of a concrete definition though?

@paulmillr
Copy link

What exactly do you need?

@mrpotes
Copy link
Author

mrpotes commented Feb 17, 2014

@paulmillr sorry for the delay in replying. Probably just a brief description of what you expect each end point to actually do. For example, I think the /auth/github just does the standard OAuth flow, with client ID and a state token (that is presumably stored in a session for verification, or something?), however, that's not clear. Similarly /auth/github/callback needs defining - is this the point at which the user's list of repos is fetched? (I notice the list of repos for your account doesn't include ostio or ostio-api, for example).

@sindresorhus I saw that @kouphax has created a todomvc-server which is also TasteStack-ish - perhaps we could have TasteMVC to cover that, and TasteREST to cover multiple implementations of the ost.io API?

@kouphax
Copy link

kouphax commented Feb 17, 2014

@mrpotes My todomvc-server project(s) predates the TasteStack stuff and has been collecting dust over the past while. Happy help revive the serve side stuff as there is a lot of interesting stuff that could be shown.

@paulmillr
Copy link

@mrpotes good idea about the details for /auth/github/callback. No problem with that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants