Django Passing data between views
Question:
I was wondering what is the ‘best’ way of passing data between views. Is it better to create invisible fields and pass it using POST or should I encode it in my URLS? Or is there a better/easier way of doing this? Sorry if this question is stupid, I’m pretty new to web programming 🙂
Thanks
Answers:
There are different ways to pass data between views. Actually this is not much different that the problem of passing data between 2 different scripts & of course some concepts of inter-process communication come in as well. Some things that come to mind are –
- GET request – First request hits view1->send data to browser -> browser redirects to view2
- POST request – (as you suggested) Same flow as above but is suitable when more data is involved
- Django session variables – This is the simplest to implement
- Client-side cookies – Can be used but there is limitations of how much data can be stored.
- Shared memory at web server level– Tricky but can be done.
- REST API’s – If you can have a stand-alone server, then that server can REST API’s to invoke views.
- Message queues – Again if a stand-alone server is possible maybe even message queues would work. i.e. first view (API) takes requests and pushes it to a queue and some other process can pop messages off and hit your second view (another API). This would decouple first and second view API’s and possibly manage load better.
- Cache – Maybe a cache like memcached can act as mediator. But then if one is going this route, its better to use Django sessions as it hides a whole lot of implementation details but if scale is a concern, memcached or redis are good options.
- Persistent storage – store data in some persistent storage mechanism like mysql. This decouples your request taking part (probably a client facing API) from processing part by having a DB in the middle.
- NoSql storages – if speed of writes are in other order of hundreds of thousands per sec, then MySql performance would become bottleneck (there are ways to get around by tweaking mysql config but its not easy). Then considering NoSql DB’s could be an alternative. e.g: dynamoDB, Redis, HBase etc.
- Stream Processing – like Storm or AWS Kinesis could be an option if your use-case is real-time computation. In fact you could use AWS Lambda in the middle as a server-less compute module which would read off and call your second view API.
Write data into a file – then the next view can read from that file (real ugly). This probably should never ever be done but putting this point here as something that should not be done.
Cant think of any more. Will update if i get any. Hope this helps in someway.
I was wondering what is the ‘best’ way of passing data between views. Is it better to create invisible fields and pass it using POST or should I encode it in my URLS? Or is there a better/easier way of doing this? Sorry if this question is stupid, I’m pretty new to web programming 🙂
Thanks
There are different ways to pass data between views. Actually this is not much different that the problem of passing data between 2 different scripts & of course some concepts of inter-process communication come in as well. Some things that come to mind are –
- GET request – First request hits view1->send data to browser -> browser redirects to view2
- POST request – (as you suggested) Same flow as above but is suitable when more data is involved
- Django session variables – This is the simplest to implement
- Client-side cookies – Can be used but there is limitations of how much data can be stored.
- Shared memory at web server level– Tricky but can be done.
- REST API’s – If you can have a stand-alone server, then that server can REST API’s to invoke views.
- Message queues – Again if a stand-alone server is possible maybe even message queues would work. i.e. first view (API) takes requests and pushes it to a queue and some other process can pop messages off and hit your second view (another API). This would decouple first and second view API’s and possibly manage load better.
- Cache – Maybe a cache like memcached can act as mediator. But then if one is going this route, its better to use Django sessions as it hides a whole lot of implementation details but if scale is a concern, memcached or redis are good options.
- Persistent storage – store data in some persistent storage mechanism like mysql. This decouples your request taking part (probably a client facing API) from processing part by having a DB in the middle.
- NoSql storages – if speed of writes are in other order of hundreds of thousands per sec, then MySql performance would become bottleneck (there are ways to get around by tweaking mysql config but its not easy). Then considering NoSql DB’s could be an alternative. e.g: dynamoDB, Redis, HBase etc.
- Stream Processing – like Storm or AWS Kinesis could be an option if your use-case is real-time computation. In fact you could use AWS Lambda in the middle as a server-less compute module which would read off and call your second view API.
Write data into a file – then the next view can read from that file (real ugly). This probably should never ever be done but putting this point here as something that should not be done.
Cant think of any more. Will update if i get any. Hope this helps in someway.