Django is a fantastic boring[1] tool, and seeing boring updates like this is great.
Django is a fantastic boring[1] tool, and seeing boring updates like this is great.
The most critical Python infrastructure (PyPi) is now built with it, if you haven't tried it give it a shot. It is one of most well thought out frameworks for python in my opinion.
I've made a tutorial for it: https://docs.pylonsproject.org/projects/pyramid-blogr/en/lat....
It's very well thought through. We're providing a GraphQL and integrating it was a breeze.
Simply add a /graphql view to your Pyramid app such as:
from cornice import Service
from pyramid.exceptions import HTTPBadRequest
from ..schemas import schema
graphql = Service(
name='graphql',
path='/graphql',
description="GraphQL",
accept='application/json',
renderer='json',
)
@graphql.post(permission='readwrite')
def post_graphql(request):
query = request.json_body.get('query')
variables = request.json_body.get('variables', None)
if not query:
raise HTTPBadRequest
return schema.execute(query, variable_values=variables, context_value={
'dbsession': request.dbsession,
'user_id': request.authenticated_userid,
})couldn't agree more
I think it’s one of if not the longest running commercial Django websites.
In this cycle all I needed to tweak was something related to `use_required_attribute` on a form, and I did that back in March. I needed to add `renderer=None` to to my form field render() method, but I did that back when it was a warning in March 2017.
In a web design context probably the biggest advantage is having things like asynchronous code where it makes sense and websockets without having to use another technology stack such as node.js.
Otherwise I simply find we are more productive using Django, it allows less boilerplate code for similar functionality, there is less complexity involved overall.
Disadvantage is maybe for really large projects with many developers, Symfony might be easier to have someone pick up the code since it's more standardized.
Community also goes a long way. Back when I dealt in PHP (+whatever framework) and switched to Django, the average competence of people I interacted with in conversations regarding the language / frameworks jumped up considerably. I like standing on the shoulders of giants.
As for the initialization stuff -- yes, that's true; whenever Django models are being imported, you do need to have had `django.setup()` called.
I'm exploring using Django Channels to send data to visualisation SPA's in realtime. https://channels.readthedocs.io/en/latest/
Most people using Django have built their apps as Django apps so this is a "non issue".
The worst way to use Django is to try and fight against the way it was built. For your case specifically, it's probably not a good option.
This is why the problem inform the solution, pick the framework (or lack of) that suits your problem best
On my current project we don't use an ORM; just SQL statements and we create classes to match the result set and map into them.
Django has it's own ORM with a different design philosophy that is optimised for a different use-case to sqlalchemy.
Django's ORM is generally cleaner and more readable for the common case and requires less code to set up. It might be slightly less elegant for more complex cases but it's a trade off that's made me pretty happy on balance.
I wrote it for my own convenience but others may find it useful.
If you're curious about the frontend path I took, it was roughly:
* jQuery with no framework
* Backbone (for a couple years)
* Backbone + Marionette (for a couple more years)
* Angular (for about a week)
* React (for the past few years)
What do you think of Vue.js?
State management with React is another story; I've used Reflux and Redux a lot, and am experimenting with Mobx now.
I'm using stuff like slickgrid[0], jquery-ui datepicker, json-editor[1] and wonder how I will drive these components from something like Angular or React?
doh, quickly googled for the github links below and saw there now a slickgrid-es6[2] fork which I have not tried. But my question still stand: how do you drive jquery libs from newer frameworks?
[0]: https://github.com/6pac/SlickGrid/wiki
Maybe it's frowned upon but I don't really like to use those (usually partial) Bootstrap re-implementation, especially in non-SPAs where you already have jQuery and/or Bootstrap.
Of course it's becoming less and less necessary.
On component mount/unmount, you can apply a jQuery library to the DOM node and optionally clean it up.
It's the same way you can wrap a <canvas> node with a React component and otherwise do all your draws outside of React (like for a game). This way the node is still integrated into your React app but React does nothing more than create/remove it.
Once you've wrapped it in a component, you can more or less drop that component anywhere in your view hierarchy and not have to think about the fact that it's using jQuery under the hood.
This highlights one of my favorite things about React and similar frameworks, which is that it's the closest thing to actual, useful encapsulation of components I've seen in a frontend framework. It's not perfect, but it's much better than everything I used before it.
If any other site tries to POST to the API on behalf of the current user they'll get a "Authentication credentials required" message.
If you don't need JWT (I'd probably leave it out next time round) then Django Rest Framework comes with a simpler bearer token auth class (among others): http://www.django-rest-framework.org/api-guide/authenticatio....
edit to add - if you're asking specifically about sharing sessions between the JS app and the Django server-side form, I believe this is what you're looking for:http://www.django-rest-framework.org/api-guide/authenticatio..., i.e. you'll still need to pass the csrf token into the JS app.