On Tuesday, November 1, 2016 at 10:00:08 AM UTC, Peter Damoc wrote: > > On Tue, Nov 1, 2016 at 11:30 AM, 'Rupert Smith' via Elm Discuss < > [email protected] <javascript:>> wrote: > >> Are you talking Elm running server side for this? >> >> I haven't thought about that too much. > In theory, there should be some kind of schema common to both the > front-end and the back end that would capture authorization requirements > but, ideally it would be something that sits mainly in the client. > Ideally it would be something similar to using Horizon. > The server side should be mainly automated. >
Its just for reasons previously discusses, I don't think your layers 1, 2 & 3 belong on the client side. How can you trust an unknown person or organisation to run your client code and not deliberately alter or bypass your business logic? Instead of posting requests to make balanced transactions between bank accounts, just add a few million to my account and then save it. If we follow Kasey's advice and make an API with endpoints for each use case, all that the client should see is the available endpoints, and the data models that they accept. Like this: Client layer: API data model + functions to invoke endpoints + some way of receiving back the responses. Server API layer: API data model + endpoints Server Business logic layer: functions/methods implementing the business logic Server Persistence layer: code to shove stuff in the database etc. There may or may not be 2 data models on the server side, one for the API and one for the database. I don't tend to automatically choose this approach, in particular I don't like code that copies from one data model to another: myDBObject.setFoo(myAPIObject.getFoo()); myDBObject.setBar(myAPIObject.getBar()); ... The reason being that more often than not, someone will add something to this data mapping that should actually be part of the business logic. Even setting a default value in the mapping should not be done, the default should instead be made very clear in the business logic. The other reason I don't like it, is that often the code that constructs the API object from the database objects is the source of N+1 selects. So I make a judgement call on where it is appropriate to use the same data model for both. -- 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.
