Notes on presentation about Drupal off the Island with MongoDB, AngularJS, more

Presented by Ian Mariano

[Need to ask NorthPoint Digital for the slide showing Drupal's API role in the whole mix:

UX: ASP.NET MVC, Angular.JS, HighCharts.JS
API/Admin: PHP/Drupal
Solr
MongoDB]

Mongo: All governments. Very flexible.

Extended MongoDB with JavaScript functions, including for forecasting data with best-fit curve projection. Also normalizing imported data, flattening data for SOLR search.

Map-Reduce: Condense large amounts of data into useful aggregated results. For example, population mapped to year. Key-value pairs, average, maximum, etc. (Not the raw data anymore, key-value pairs for useful aggregates.

Aggregation pipeline, simpler than map-reduce, like piping in UNIX.

Govalytics module manages MongoDB collections defining regions, normalized names for government functions (public safety etc), etc.

Epose REST API to the front end.

PHP / Drupal: Custom Drupal module, REST API to abstract access to MongoDB, management of app-specific data...

Data without context is without meaning. What is the story behind it and how will it be used).

It's still an ongoing process, because it's humans and machines working together.

MariaDB for Drupal's usual

We're using the Mongo client in PHP, not Mongo module or anything. Our module talks directly to Mongo.

Thinking of doing Drupal nodes for Mongo records, to allow workflow around it.

Index still fits in

Isolate the clients from any sharding issues going on underneath.

REST API is between Angular JS front end and PHP API. Took a stab at Services module, just did straight PHP and modified the .htaccess for it. Had also considered theming it for JSON

Client already had ASP.net.

Everything is service based, it could have been Angular and high chart on top of Drupal just as easily.

Data versioning is essentially a hot copy of the government data with a date, can be one at a time. One of future things we talked about is representing Drupal as a content node, and then distinguish between pre-release, live, and archive data. You can couple it as long as you have the pointers. We have a place in Mongo for the content node ID. Could use mongo id, but safer to be explicit.

One of the things touted in mid 1990s to 2000 was service oriented architecture. Your database should be independent from your

your load balancers should [be able to be]

search should not be tightly coupled

Front end should not know anything about the database, it should just know it can call an API when it needs it.

You can scale elastically.

XML is a larger payload, and extracting data is

As long as the API signatures remain the same, the

Everything is a web service call [from the front end]. They could extend this and start using native devices to reach the API, or allow other people to access the API directly.