RFC#1 : Open API/Web Site Frontend Relationship

[daviddyess]

When I was going at this alone, I intended to have the Open API separate from the web site, mostly for availability. Do we want to have the API and the web site decoupled or provide the API as an optional output to the web site? Obviously a dedicated database for the web site would be better performance-wise, but then there is a chance of degrading performance of the web site if the API is in higher demand. Also, if they are separate (decoupled), we have the potential to have mirrored entry points to the open API.

Option A: Open API is separate from the web site (physically) and the web site uses the REST API, along with a dedicated database just for the web site.

Option B: The web site also powers the Open API.

If you have another option, please add it in a comment.

[Korlimann]

If we want to try and host it on my friends server, we'll probably have to add the database to the website, because of his upload rate. Of course, we could avoid this by hosting with a professional hosting website, but we should definitely decide with the rest how we want to host. Option A sounds pretty good to me though, if we'd go with my friend hosting the server

[daviddyess]

I have shared hosting accounts and a linode instance, so I don't think hosting will be an issue, there are lots of options there. This is more of an architecture concern than a hosting concern, for me anyway.

[pscn]

I'm also in favor of option A: Provide an open API with access restricted by an API key. With API keys we have the option to e. g. limit the requests per minute for other applications, if we run into performance issues. And we have a good overview about who is using the service.

With that being said, I still haven't wrapped my head around the scope of the API and the web site :)

Right now I'm thinking: API: flavors Web Site: users, recipes and all the rest

If it's like that, how will updates to flavors be authenticated. Do we need an extra front end to the API to perform updates? As discussed on discord I'd like the flavor managment to be a little like what musicbrainz does. There are certain actions that can be auto applied (e. g. add a manufacturer or a flavor) and others that need review, but may auto apply after some time (e. g. rename a manufacturer or flavor). Before I speculate more, am I on the right track with my assumption?

[daviddyess]

The API can be as wide as we want. If we go with option A, I think it would be a good idea to have a simple user system specific to it that will allow us to assign roles and provide users with tailored export features. This would also allow other tools to get users' flavor stashes.

In addition to flavors and vendors, I intended to have a tagging system and categorization (filters) built in for optional querying filters and flavor stashes for users (supplemented by web site features)

On Sat, May 4, 2019, 1:06 PM Peter S. notifications@github.com wrote:

I'm also in favor of option A: Provide an open API with access restricted by an API key. With API keys, we have the option to e. g. limit the requests per minute for other applications if we run into performance issues. And we have a good overview about who is using the service.

With that being said, I still haven't wrappen my head around the scope of the API and the web site :)

Right now I'm thinking: API: flavors Web Site: users, recipes and all the rest

If it's like that, how will updates to flavors be authenticated. Do we need an extra front end to the API to perform updates? As discussed on discord I'd like the flavor managment to be a little like what musicbrainz does. There are certain actions that can be auto applied (e. g. add a manufacturer or a flavor) and others that need review, but may auto apply after some time (e. g. rename a manufacturer or flavor). Before I speculate more, am I on the right track with my assumption?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Korlimann/MixnJuice/issues/1#issuecomment-489356146, or mute the thread https://github.com/notifications/unsubscribe-auth/AACDNYTSG5AA2WRH66AN3R3PTXNERANCNFSM4HKZM7LQ .

[pscn]

So every user from the web site does also exist on the API side?

So if in the future ELR or ATF or anyone else would use the API too, the users could link up to their account on the API and have their stash available instantly? I would like that. But I'm not sure right now if I like the wide scope of that API. I need to think about that...

[Korlimann]

Having one really good API with not only the flavours but users (and maybe recipes) too that every site can use sounds amazing to me. Everyone could use it and build their own layout using the API, so if you don't like layout A, simply go to the other website which uses layout B and log in using your same credentials. I'd definitely go with the API Key too.

[ayan4m1]

In terms of not needing to create an account with the site, OpenID sounds like what you want for that. "Federated authentication" is the jargon to research.

For allowing people access to their own recipes programmatically, all you need is an API, could be as simple as a token could be as complex as OAuth 2.

If you want to allow other services to access our site data on behalf of a user, then OAuth 2 is almost certainly what you want.

[daviddyess]

Giving this one some more time for comments and then I'll comment a summary statement for closure and possible acceptance.

[daviddyess]

As far as openID, I'm a big supporter of it in general and I think it's an option we should allow (as well as google/facebook/etc), but keep in mind you still have to maintain a record of the user, so it doesn't void the requirement for a user database.

[daviddyess]

Definitely +1 for OAuth2 support