Highlights: * 16:49 - include the path in the id * 20:15 - use a URL instead of the id * 27:30 - best practices / implementation bias * 29:06 - indexed collection bias
I wouldn't say it's entity-oriented but for sure it would need a shared model. But for me it looks more like RPC. You have a fixed endpoint - like /graphql - and then you have a lot of autonomy as long as you know the data model.
I use JAX-RS to automatically Marshal and unmarsahl JSON into Java objects. Having a string like "/pet/12345" as ID instead of just 12345 would mean the parses won't work. or I will have to create an additional property in every entity to hold the string value and then extract the integer ID in post processing. Same for the other direction. Plus I probably have to name the string version of ID as id and the native integer id as int_Id or _id. So the string hack takes up the proper name "id" and the actual integer ID gets a second class name. The clean flow from database to JSON using generic code is also disturbed. Any suggestions?
Your JAX-RS implementation has to have a marshaller which does the convertion and it's usually well configurable. Suppose Jersey with Jackson. Then you can configure the marshaller to use only your getters/setters (actually this is the default for Jackson). So even if you have a "long" id (as a private field) you just have to provide a String getter for it. Or you can use custom serializers. But by the way you may rethink your design altogether based on the statement at 13:16 - decoupling your rest domain from your data access layer. (And this can even be somewhat automated with e.g. Spring Data REST - despite that at first sight it seems that it just exposes your persistent entities: www.infoq.com/presentations/ddd-rest/#anch142195 )
Highlights:
* 16:49 - include the path in the id
* 20:15 - use a URL instead of the id
* 27:30 - best practices / implementation bias
* 29:06 - indexed collection bias
Would have liked more if GraphQL APIs were also discussed along side REST & RPC. Moreover, nice explanation... Thanks
I think it is more valuable for front frontend and this talk is more about backend
I wouldn't say it's entity-oriented but for sure it would need a shared model. But for me it looks more like RPC. You have a fixed endpoint - like /graphql - and then you have a lot of autonomy as long as you know the data model.
Start at 5:00
At 4:27 actually but yeah
I use JAX-RS to automatically Marshal and unmarsahl JSON into Java objects. Having a string like "/pet/12345" as ID instead of just 12345 would mean the parses won't work. or I will have to create an additional property in every entity to hold the string value and then extract the integer ID in post processing. Same for the other direction. Plus I probably have to name the string version of ID as id and the native integer id as int_Id or _id. So the string hack takes up the proper name "id" and the actual integer ID gets a second class name. The clean flow from database to JSON using generic code is also disturbed. Any suggestions?
Your JAX-RS implementation has to have a marshaller which does the convertion and it's usually well configurable. Suppose Jersey with Jackson. Then you can configure the marshaller to use only your getters/setters (actually this is the default for Jackson). So even if you have a "long" id (as a private field) you just have to provide a String getter for it. Or you can use custom serializers.
But by the way you may rethink your design altogether based on the statement at 13:16 - decoupling your rest domain from your data access layer. (And this can even be somewhat automated with e.g. Spring Data REST - despite that at first sight it seems that it just exposes your persistent entities: www.infoq.com/presentations/ddd-rest/#anch142195 )
This was a good place for me to start
entity oriented and procedure oriented maps to OO and functional it seems
This is mind blower. Actually helps a lot of stuff I am working on. Does anyone happen to have those slides?
Love this talk by Martin Nally
Thanks very good talk !
Good and clear talk! 👍
I like this one
Very bad ideas, i'm shocked you are in google cloud.
Good but boring and slow!