Django's role in a polyglot world
=================================

David Gouldin
@dgouldin
slides - https://django-ployglot.herokuapp.com

- Django is 10 years old
- it is not a CMS (but was built to make one)
- used to be LAMP - one (relational) datastore, all on one server
- now much more service orientated - can even treat the web browser as a service that runs stuff
- expectations for responsiveness, "app-like"

Django strengths

- python
- "perfectionists with deadlines"
- orm & migrations (though doesn't cover entire SQL standard)
- the admin
- django rest framework (for REST API)
- celery (async work queue)

Django weaknesses

- c10k - 10000 concurrent connections to web service - alternatives async.io, twisted, but lose library support

JS client integration

- community then expect JS on the server

Push to web clients

- no good solution in Django - long connections - but kills server
- polyglot can use socket.io, websocketd, golang

async task results

- add task ids to initial response
- then have client poll other endpoint to get status of task id
- OR can use pubsub/async to subscribe to task, and then result gets pushed to client

- react.js - but then need js running on the server
- run node on server - React.renderToString(BaseElement)
- can have node on separate subdomain - have node to initial web page, then have Django as a service provider

Shared auth across services

- django.contrib.auth
- have node proxy auth to django
- access token, check with django
- have separate auth service that django and others use - but more heavyweight

Take away points
----------------

- Say no to full stack python - not feasible for the web
- HTTP is your friend (and pubsub is the back up)
- Think about web browsers as service consumers

Questions
---------

- when is it worth the effort?  When it seems like a webapp - plain webpage (eg blog) doesn't need it
- testing? service contracts are really important - can test each service in isolation, and then just do a few integration tests