0

Currently I am working on a portal which is exposed to end users. This portal is developed using Python 2.7, Django 1.6 and MySQL.

Now we want to expose this portal as a mobile app. But current design does not support that as templates, views and database are tightly coupled with each other. So we decided to re-architect the whole portal. After some research I found following:

  1. Client side: AngularJS for all client side operations like show data and get data using ajax.
  2. Server side: Rest API exposed to AngularJS. This Rest API can be developed using either Tastypie or Django Rest Framework (still not decided). Rest API will be exposed over Django.

I have few questions:

  1. What you guys think about architecture? Is this is a good or bad design? How it can be improved?
  2. Will performance of portal will go down after adding above layers in architecture?
  3. In the above architecture whether 2 servers should be used to run this (like one for client and other for serving the API's) or one server will be enough. Currently Heroku is used for deployment.

Currently portal is getting 10K hits in a day and it is expected to go to 100K a day in 6 months. Will be happy to provide more information if needed.

anuragal
  • 3,024
  • 19
  • 27
  • What does node.js have to do with anything here? The API is being served by Django, what would another server do? – Daniel Roseman Feb 27 '14 at 12:29
  • Yes, If you are using Django than you don't need to use node.js and just for client side performance you can implement KnockoutJS or AngularJS. – CrazyGeek Feb 27 '14 at 12:48
  • @DanielRoseman and CrazyGeek:- My thought process was to use 2 different servers for client and server. So that they can be deployed on different servers. This might be a bad idea but looking for your opinion on this. My bad for writing node.js but replace it with some web server that i can use for client side. edited my question. – anuragal Feb 27 '14 at 13:08
  • But the client side is just static templates, no? You don't need anything more than a static server - nginx would do, but so probably would whatever is serving your Django stuff. – Daniel Roseman Feb 27 '14 at 13:44
  • @DanielRoseman Yes your are right.. I am more interested in knowing whether using 2 servers will provide any help in performance? What is your take on my architecture.. is it fine or it need some improvements? – anuragal Feb 27 '14 at 14:17
  • Why I am giving emphasis on 2 servers is because the API will be called from both web portal and mobile app so is it good to keep 2 servers or it will not make any impact on performance. – anuragal Feb 27 '14 at 15:34

2 Answers2

0

If i got an opportunity to architect the portal which you mentioned than i would really love to design the architecture which i have already explained here.

Community
  • 1
  • 1
CrazyGeek
  • 3,397
  • 2
  • 24
  • 38
  • Your suggestion will make us force to rewrite the whole application. Currently we are using MYSQL and we have lots of end user data into it. But PyPy is a good idea will read more about it. – anuragal Feb 27 '14 at 12:12
  • You don't need to rewrite whole application as you can convert your MySQL data into mongoDB using this importer https://code.google.com/p/sql-to-nosql-importer/ and mongoengine supports ORM likes API. Without touching your production you can give a try to this. If it get successd than your portal will be great. – CrazyGeek Feb 27 '14 at 12:46
  • The portal will be great even without NoSQL decisions. MongoDB can bring a mess into the project, if it requires **transactional support** (TX logic will migrate from DB to business logic code - it would reqiure TX manager implementation, which is not trivial) or they have **join queries**. MySQL can be denormalized and turned into smth similar to key-value storage. PostgreSQL can be turned into json-document oriented storage. But this is another story... – Mr_Mig Feb 28 '14 at 18:12
0

What you guys think about architecture?

This is a common Service Oriented Architecture with decoupled Clients. You just have REST endpoints on your backend, and any Client can consume those endpoints.

You should also think about:

  1. Do you need RESTful service (RESTful == stateless, will you store any state on the server?)
  2. How to scale the service in the future? (this is a legit thing as you already aware of huge traffic increase and assume 2 servers)

How it can be improved?

Use scala instead of python :)

Will performance of portal will go down after adding above layers in architecture?

It depends.

It will get some performance penalty (any additional abtract layer has it's tax), but most probably you won't event notice it. But still, you should measure it using some stress tests.

In the above architecture whether 2 servers should be used to run this (like one for client and other for serving the API's) or one server will be enough. Currently Heroku is used for deployment.

Well, as usual, it depends.

It depends on the usage profile you have right now and on the resources available. If you are interested in whether the new design will perform better than the old one? - there are a number of parameters.

Resume

This is a good overall approach for the system with different clients.

It will allow you:

  1. Totally decouple mobile app and frontend development from backend development. (It could be different independent teams, outsourceable)
  2. Standardize your API layer (as all clients will consume the same endpoints)
  3. Make you service scalable easier (this includes the separate webserver for static assets and many more).
Mr_Mig
  • 783
  • 5
  • 10