O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 17 Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Charles Ivie (20)

Anúncio

Mais de Connected Data World (20)

Mais recentes (20)

Anúncio

Charles Ivie

  1. 1. Micro-Servicing Linked Data Architectural choices Charles Ivie – Director at Semantic Integration Ltd. charles.ivie@semanticintegration.co.uk Connected Data London
  2. 2. Micro Services
  3. 3. Micro Services
  4. 4. Micro Services
  5. 5. Micro Services
  6. 6. Micro Services
  7. 7. Micro Services
  8. 8. Micro Services
  9. 9. Micro Services
  10. 10. So what is our recipe for… • Linked Data • Fluid data model (Like a Triplestore) • Powerful query language (Sparql - esk) • Distinct proper Micro Services • Use standards where possible
  11. 11. Linked Data Micro Services
  12. 12. Linked data = URI’s
  13. 13. Linked Data Micro Services
  14. 14. GraphQL auto configuration
  15. 15. GraphQL query Example query
  16. 16. HyperGraphQL http://hypergraphql.org “An open source GraphQL query interface for RDF triple stores.” • Open Source • Configurable to any Sparql endpoint • Fully abstracted away from Triplestore • Responds with JSON-LD
  17. 17. HyperGraphQL http://hypergraphql.org/graphiql Try it out on our demo server… Linked to DBpedia data

Notas do Editor

  • Lots of well documented and understood features and benefits.
    Dedicated storage solution per micro service
    Not without complexity in construction in link rich data models
    Not great for a truly fluid data model
    Popular well understood architecture


  • Often the micro services data is brought together in an aggregation layer, creating the full picture and UX



  • Code changes made to a micro service obviously need to be realissed through the architecture



  • Code changes made to a micro service obviously need to be realissed through the architecture
    A very complex network of MicroServices can actually cause a lot of engineering effort



  • Innovation in making services easier to manage has improvved the complexity
    But not solved it completely



  • In some cases the microservices themselves become interlinked, and dependancies start to occur



  • In some cases the microservices themselves become interlinked, and dependancies start to occur



  • Linked data in a triplestore means the model is fluid
    Many of the same problems still exist
    Triplestore goes down, everything goes down
    A breaking change in the data could effect all services



  • No large database underneith
    Bu how do we aggregate?
    How do we perform complex querying?
    How is the data linked?




  • No monolithic data source (Triplestore)
    Data stored as simple local JSON documents
    We have tried to marry the two worlds
    Use distinct URI’s for all the semantic web reasons ()
    Implicitly linked data




  • Added in GraphQL for complex rich querying




  • GraphQL implemented to understand HATEOAS
    JSON Schema’s can be read by GraphQL to automatically understand the model
    Automatically can understand the Micro services, with no besboke implementaiton per micro service
    New services can be added without re-development of GraphQL
    Model can change
    Dynamic CMS app can automatically change with the model
  • The result of this is a product catalogue navigable from a GraphQL query
  • Another approach we have been looking into for GraphQL has resulted in an open source project
  • Try it out

×