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
@SiddharthKulkarniN4 жыл бұрын
Start at 5:00
@DanDascalescu-dandv Жыл бұрын
At 4:27 actually but yeah
@krtirtho4 жыл бұрын
Would have liked more if GraphQL APIs were also discussed along side REST & RPC. Moreover, nice explanation... Thanks
@bhaveshtiwari57833 жыл бұрын
I think it is more valuable for front frontend and this talk is more about backend
@LogicPhalanx2 жыл бұрын
I think you can consider GraphQL to be an entity-oriented API.
@IgorDonin2 жыл бұрын
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.
@bocckoka2 жыл бұрын
entity oriented and procedure oriented maps to OO and functional it seems
@jahmanichauvet3604 жыл бұрын
This was a good place for me to start
@lhxperimental6 жыл бұрын
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?
@mihu864 жыл бұрын
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 )
@mcnianliu2 жыл бұрын
This is mind blower. Actually helps a lot of stuff I am working on. Does anyone happen to have those slides?
@parthibansrinivasan91826 жыл бұрын
Love this talk by Martin Nally
@almostrandomnickname2 жыл бұрын
Thanks very good talk !
@antonpirhonen96984 жыл бұрын
Good and clear talk! 👍
@gatsdev4 жыл бұрын
I like this one
@RamiiYoussef Жыл бұрын
Very bad ideas, i'm shocked you are in google cloud.