I am currently working on a Django web application consisting of following parts:
API (Django-REST-Framework) Finished
Custom administration page Unfinished
For super users
For normal users
The API app which has currently been finished has all the models for the entire system hence it made most sense. Now what i'm very uncertain about is if i should build the administration page inside of the API app, or create a separate app for that purpose? I will still need to refer to an external model, and will this be painless to maintain in the future?
I am not fully certain how the app structuring should be handled in my certain use-case.
According to advises i ended up creating separate apps to keep clean structure in the code.
Related
I'm currently working on a project which would require some realtime functionalities such as Multi-user chatrooms etc.
Ideally, I’m looking to have meteor run the chat application(on a different port) and mongodb act as message broker to the django back-end which would take care of user registration , management and everything 'non-realtime' related.
This would involve setting up a reverse-proxy which would redirect to a different port based on the url (please let me know if i'm wrong in this)
Would this be possible(or even advisable)? Another option would be to implement the same with tornado. but I have no experience with building tornado-based apps and rather do this with a framework I’m comfortable with.
Thanks,
You can have Django serve the Meteor front-end while providing access to its data using django-ddp, giving you some distinct advantages:
Continue to serve your existing Django project/apps.
No extra services or ports to manage.
Scale out by simply adding more front-end Python/Django servers (server to server IPC is done via the existing database connection).
Use django.contrib.auth user accounts in your Meteor app.
Familiar Python/Django code (no "callback" style such as with Tornado).
Use time-tested, trusted relational databases.
Use Django migrations to effectively manage schema changes.
There's a Gitter chat room where I can give you assistance if you need it.
DISCLAIMER: I'm the author of django-ddp.
A meteor application is more than capable of handling the user registration flow and many other things. Why not just build the application entirely in meteor? Your application sounds like a perfect candidate for meteor, with realtime interaction with your database at the core.
The other option would be to use swampdragon which adds realtime data binding within django. It allows for simple bi directional communication between the server and the client. Again, essential for a chat application. It nice and easy to get setup and running as well.
Are there any specific reasons to not implementing your application in one framework alone?
I am setting up a server for my android chat app. It is a pure group chat i.e. each message will be sent to multiple users and not just a single user
Since I have a background in Python, I would prefer to pick a python based web framework.
So as I was searching, I came across "Django" and "DjangoREST". After reading a lot about them, it seems that DRF (Django Rest Framework) is a RESTful implementation of Django and will let you make applications that are light and scalable.
Since this is for the first time that I am setting up a web service, I can not relate or understand this completely. Also, I feel that what I want to accomplish, could be accomplished on either of the 2 platforms.
Therefore, it will be great if some one could share some very basic and key differences(if any) between the 2 frameworks. So that I can decide which on to pick up.
There are no differences. Django is a web framework and Django Rest Framework makes it easier to create REST services in Django itself.
It doesn't replace Django. It adds to it.
I'm writing Django application (social network) and thinking about dividing monolithic project to two projects: UI and API. For example, Django will be used only to render pages, interacting with and taking data from API, written on web.py.
Pros are following:
I can develop and test API independently.
In the future, other UI can appears (mobile, for example), it will require service.
I plan to outsource web UI developing, so, if my application will have two modules, I can provide outside only UI one, not sharing logic of application.
Cons are following:
I'm working alone, and developing two projects are harder, then one.
I will not be able to use cool Django admin panel. I will need to write my own.
web.py is more low-level comparing with Django.
It's like a brain dump, but I will be really appreciated if you share your experience in creating web application with UI module and independent API module.
Update (more specific question, as Mike asked)
What Python framework will you use for creating REST API of social network, which can be used by different client applications? Is using web.py that returns JSON only and rendering it by Django for web is good idea?
Thanks,
Boris.
I've been in a situation similar to yours. I ended up writing both, the UI and the API part in Django. Currently, I am serving them both out of the same process/project. You mentioned you wanted to be able to outsource the UI development, but do hear me out.
In the meantime, I have used django-piston to implement the RESTful front end, but a bit of preparation went into it:
Encapsulate all DB and ORM accesses into a library. You can do that either for your entire project, or on an app by app basis. The library is not just a low-level wrapper around your DB accesses, but also can be for higher-level 'questions', such as "all_comments_posted_by_friends()" or something. This accomplishes two things:
You can call your pre-canned queries from UI views as well as API views without having to re-implement them in multiple places.
You will later be able to replace some - if not all - of the underlying DB logic if you ever feel like going to a NoSQL database, for example, to some other distributed storage model. You can setup your entire app of this ahead of time, without actually having to worry about the complicated details of this right at the start.
The authentication layer for the API was able to accept an HMAC/token based header for programmatic access and normal Django auth. I setup the views in such a way that they would render plain JSON for the programmatic clients (based on content-type), and would render the data structure in HTML (with clickable links and clickable docstrings) if browsed by a human from a browser. This makes it possible that the API is fully explorable and clickable by a human without having to read any docs, while at the same time it can be easily processed by a client just via JSON.
On effect, the database layer I build serves as the internal API. This same database layer can be used from multiple applications, multiple processes, if you wish to do so. The UI views and the REST views were both implemented in Django. They can either be in the same process or in separate processes (as long as they have access to the same database right now).
I'm new to Django and trying to understand the preferred means of operation when deploying web applications.
Let's say I'm making a web application with (for example) user login management, some uploading functionality, manipulation of uploaded files, and rendering uploaded files on screen. They're all part of the same "web application".
Would each of these functions be its own app in the project, or should these all be together a single app? Is a Django app intended to correspond to a web application, or does it correspond to a single set of functions interfacing with a few tables in the database?
There's a distinction to be made between reusable apps and non-reusable apps. For reusable apps it's essential that they offer well defined functionality and are intended to solve a well defined problem. If this wasn't the case, they wouldn't be very reusable.
However you're likely to also have some non-reusable apps, i.e. one or more apps in a project that implement application logic that's specific to the project. In my projects I always have a non-reusable app called core that acts as glue and ties everything together. If I have distinct sections in my site I may choose to have more non-reusable apps, because I like the way it essentially namespaces my project (e.g. models, views, templates, etc.)
A Django app is a group of related functionality used to complete or maintain one aspect of a site. The web application you describe would be separated into at least 2 Django apps, depending on how granular you want to make the handling of the uploaded files.
I have an application built with Django. Part of it relies on data that I aggregate from other websites. Wondering how I should approach building the scraper/aggregator.
The advantages I see of building it as a Django app is
the ability to use Django's models & database API
the ability to use Django's other methods
On the other hand I think the disadvantage would be scalability in the long run.
Should I build the scraper/aggregator as an app in my Django project or as a separate script that runs on its own?
Would love to hear your thoughts.
Neither of your points require it to run within Django. And since it will not be dependent on the web/HTTP interface, having it be a separate module is the only option that makes sense.
I just have published a Django app django-dynamic-scraper on GitHub, which is build on top of the scraping framework Scrapy and where you can build Scrapy scrapers in the Django admin and use Django model classes to store your scraped data, maybe this is of some use for people with similar problems.
If it's a django app, it will only run when someone loads the page. That could slow the loading.
Making another script could be a nicer idea but could produce inaccurate data.
I think it actually depends on the context.