Extensible Database APIs andtheir role in SoftwareArchitectureMax Neunhöffer

Education Tech + Cold Beer (SF) 4 March 2015

www.arangodb.com

Typical structure of an applicationDatabase ←→ App Server ←→ Browser

←→ Mobile App(keeps state) (is stateless) (on user’s machine)

Communications flow:data −→ create view −→ display viewpersist ←− react ←− user action

complex queriesdifferent views for different frontendswant to scale DB and app server separately

1

Agile developmentFacts of life as a software developer/architectSoftware grows, we release frequently and quickly, giverapid feedback, one learns as one goes.

In the beginning . . .the data schema is unclearthe scope of the app is unclearthe list of front end devices is unclearprotocols are not yet sorted outperformance bottlenecks are unknownsecurity requirements and problems are unclear

All these are good things!2

MicroservicesThese days, everybody talks about microservices:

http://martinfowler.com/articles/microservices.html

Features of a microservice architectureIt is a “particular way of designing software app-lications as suites of independently deployableservices.”We cut the application into services,built around business capabilities. They areindependently deployable (fully automatically!)have well-defined interfaces (often via REST/HTTP),and typically run in their own process.

3

Initial phase: hack away, rapid prototyping

Features:focused on quick resultsthe database schema keeps changingperformance does not really matterno securitythe user interface undergoes many changesoften just a single target frontend

4

Consolidation phaseFeatures:

home in on protocols, stabilize themschema stabilizesmaybe more devices and different front-endsuser interface is understood betterstart to think about securityobserve first performance problemsadd unit tests

5

Polishing phase

Features:quality becomes more importantsecurity as wellwe know, which front-ends must be supportedthe protocols are fixed and documentedthe schema is fixed, we want to enforce itperformance matters

6

The role of the Databaseearly late

schema:flexible, quick results enforcementprotocol:use standard API use specialized servicesauthorization:does not matter matters greatly (want to be flexible)security:does not matter matters greatly (want to be hardened)performance:does not matter mission critical(no real example data) (have a lot of data)

Conclusion: DB needs to change!7

WANTED: (better alive than dead)

a smart databasethat can be adapted over timewhose API is extensiblecan run performance critical complex queries in the DB,expose them as data-centric microservices via RESThas configurable consistencyhas configurable security features

8

is a multi-model database (document store & graph database),is open source and free (Apache 2 license),offers convenient queries (via HTTP/REST and AQL),including joins between different collections,configurable consistency guarantees using transactionsis memory efficient by shape detection,uses JavaScript throughout (Google’s V8 built into server),API extensible by JS code in the Foxx Microservice Framework,offers many drivers for a wide range of languages,is easy to use with web front end and good documentation,and enjoys good community as well as professional support.

9

Extensible through JavaScript and FoxxThe HTTP API of ArangoDB

can be extended by user-defined JavaScript code,that is executed in the DB server for high performance.This is formalised by the Foxx microservice framework,which allows to implement complex, user-defined APIs withdirect access to the DB engine.Very flexible and secure authentication schemes can beimplemented conveniently by the user in JavaScript.Because JavaScript runs everywhere (in the DB server as wellas in the browser), one can use the same libraries in theback-end and in the front-end.=⇒ can implement your own data-centric microservices

10

Links

https://www.arangodb.com

http://guesser.9hoeffer.de:8000

https://github.com/ArangoDB/guesser

11