My company has created multiple enterprise applications over the past 15 years that now needs to gradually migrate to the web. I've created a pilot app using Django showcasing it's powers and how each legacy app can be converted.
For now the MVC architecture was the best solution proposed. Among the other architectures was a full Java stack that made use of JBPM for it's workflow management which my boss needed and asked if we could somehow make use of JBPM and preferably not some other BPM - 'cuase of it's powers.
The idea is to create multiple Django powered applications that each work on their own and then use JBPM to connect some of the Django services/views together in a workflow manner.
The question is can this be done?
I don't see why not:
Django can interact with webservices -- which is what you could use in order to interact with jBPM from the Django applications, and vice versa. A quick google implied that web services were easy enough to implement in order to interact with a Django frontend (from jBPM in this case).
Related
I'm building a POS(Point of sale) web application using Django for my client. This is a single instance web app.
I just want to know, should I build APIs to separate Backend and Frontend?
Whare are the benefits to build the APIs?
First and most importantly, each design decision you take for your application should be for a reason. There is no good or bad approaches, however, the approach you decide on should be based on your use-case.
I don't see any problem for having a monolithic Django application to service a single/multiple POS with limited number of users. Tens of thousands of Django applications out-there not using APIs and performing well.
That being said, if you are developing a POS solution and planning to offer it to public as SAAS (software as a service), then you might need to consider using APIs, have plans for scaling/support/patching/monitoring/upgrade/ CI and CD activities. On the other hand, if might be planning to have a Mobile application in the future; That might be another good reason to have APIs.
I am working on a project to create an online medical booking system using Dialogflow as the frontend to provide users with a more personable experience.
So far I have come up with an ideal stack PIC. I plan to have it hosted on AWS (or GCP). However, I am new to Dialogflow but I know it is a very powerful platform. My two criteria are: (A) A stack that makes it easy to personalize frontend UI display and (B) Scalability, I am starting with a web app but would like to also develop an iOS app.
I have two questions: (1) Would you change anything in the stack? and (2) Is there a way to change the name of the bot each time user visits (to make it more "real")?
Super appreciative of you guys expert opinion :)
IMHO, I've found GCP to be easier to use than AWS, since Google handles SSL encryption with .app domains, while AWS requires a more manual solution. Google Cloud also offers a terminal window inside a Chrome tab, which can be a fun experience. So, for hosting, I recommend Google Cloud, unless AWS has a unique feature that applies to your personal circumstances.
Personally, I prefer Angular to React, but Angular, React, and VueJS are all fine choices for a front-end framework on a web app. Your choice of these probably depends on which framework you already know, or (if you plan to outsource development) which language you can use to hire better engineering talent.
For my own projects, I use Express and Node on the server side, instead of GraphQL and Prisma. Your call there.
Good luck!
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 plan to make an online game. It will be a full real-time during play. For my website backend I have used Django. Database and other things are almost done. What is the best way to make user client side and server side backend for play in realtime? As I use Django it would be nice to have it in Python.
We plan that there will be minimum ~1000 online players all the time.
Twisted/Tornado/Node.js or maybe something else?
Thanks in advance.
Tornado is very light and pretty nice in my opinion. You could integrate it with Django in various ways -- e.g. Integrate Tornado in Django, Integrating Django with Tornado's web server -- or just run it alongside Django behind whatever web server you use.
Node is so fun that you might tire of Django. :-)
I think you should keep separately Django - which is used for general site functions, and Tornado - which is used for realtime data. I think you should use some Redis to store/read data and communicate between django and tornado, so prevent using database access directly from tornado.
Developing your own backend server sounds as interesting project.
But from my experience it becomes a very significant of your R&D effort.
It starts with developing core backend components, dealing with servers, installs, patches, security issues and more.
On top of it, you will need to create admin systems to manage your player, levels, xp, integration to stores and more... and then, you have the reports (installs, retention, etc'...)
I would strongly recommend using existing backend platforms.
I have a specific question about Java EE architecture. I have an application that requires several components:
A web service and persistence layer (cxf/hibernate)
A management / configuration console (Struts2/JSP?)
One or more user "applications" (Maybe Vaadin?)
Note, the web service will provide services to the user applications.
The web service has been built as a cxf/glassfish application (Eclipse dynamic we app) and is working well.
Should the management and user applications be developed as entirely separate applications (EJB's or ?) or form part of a "single" application with the web service. I am not sure if I am explaining this well enough - but I am new to this sort of design and am trying to approach the solution in a well structured way. For example I could imagine that taking an approach of separate services (applications) could result in:
Primary web service (does common data persistence stuff)
Authentication service
Management App service
First user App service
Second user App service
Each of the user apps is likely to have both common and unique data persistence requirements.
To decide how to split your implementation, you should consider your system through different views. In software architecture, there is a very useful method which is called the 4+1 architectural view model (http://en.wikipedia.org/wiki/4%2B1_architectural_view_model). Using the Physical view you will be able to decide if you may need to install the different components in different machines, and this will help you to define your development view, that will give you the answer to your question -> how to split the different components of your system in a development point of view. Once you have the development view, you can define how the components communicate (process view)... and so on.
This views have always helped me, I hope you find it useful.