So to phrase what I previously said a different way, a database is the wrong level of abstraction to be shooting for. A database is just one integration that most business systems have.
The system itself exposes use cases and queries. Whether and which databases are involved (and their structural details, I contend) should be of no concern to client apps. The client apps exist to help the user fulfill the system's use cases, not just to connect to a database. On Tuesday, October 25, 2016 at 6:02:45 AM UTC-5, Rupert Smith wrote: > > On Tuesday, October 25, 2016 at 10:01:48 AM UTC+1, Peter Damoc wrote: >> >> On Tue, Oct 25, 2016 at 11:27 AM, 'Rupert Smith' via Elm Discuss < >> [email protected]> wrote: >> >>> If your 'persistence API' requires the application to behave correctly >>> in order to not store invalid or maliciously altered data, you cannot >>> guarantee that. >>> >> >> This actually sounds more like a challenge to be faced rather that a >> technical impossibility. >> Maybe some kind of declarative access control embedded in a shared schema >> could solve this. >> > > Declaring what the access rights are to the client UI is useful, yes - it > is just that they still need to be enforced by the server because you > cannot fully trust the client to take care of it. This is actually what I > am doing (in some cases), because when a user logs in they get back a JWT > token. This token contains some information about who the user is, and what > permissions they have. The UI can use this to only render screens and > functionality that the user is allowed to use. This is merely to be helpful > and provide a nice user experience, the permissions are always checked > whenever a restricted API endpoint is invoked. > > I don't always use the JWT tokens as bearer tokens in an HTTP > Authorization header field, or as a secure cookie because they can grow > quite large. However, I generally do provide an endpoint in my API where > the JWT token can be requested in order to inspect the users declared > access rights. > > >> I do think that these server side responsibilities are not really within >>> the domain of Elm. >> >> >> Look at what happened with Javascript. Once it got useful in the client >> people wanted it on the server and then we got Node. >> We are nowhere near the popularity of javascript and yet, I already see >> frequent enough questions about using Elm on the server-side. >> >> There are two ways to address this: >> 1. allocating resources to making Elm viable on the server >> 2. making the server part as small and automatic as possible as to not >> require much coding. >> >> To me, option 2 is much more attractive. >> > > Ok, I think I now get a better idea of what you are after. As per John > Kellys PostgREST code: https://github.com/john-kelly/elm-postgrest. Have > a way of defining a data model in Elm, and use that description to > automatically generate a suitable server to persist it. > > In this case defining the access rights in the Elm code would be ok, as > the server that you generate would also securely check them at runtime. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
