I come from a Django background, where to add functionality to the site you make an app. You can share that app between other Django projects.
In the Node world I haven't really seen anything like this. However, I want to write code that is reusable and useful to the community. So I'm wondering:
Do Node programmers share apps?
How would I structure an app so that it would be easy for someone to add to their site?
Node.js developers share functional packages of code called modules through the npm registry. The modules are used the same way as the modules shown in the documentation, and are typically utilized with require(). However, do take note that Django is a web framework, and Node is a programming language. Node is to Python as something like Express would be to Django.
There isn't any specific way to structure a Node module. You just need to make sure that the package.json file is configured correctly so that the module can download any dependencies, set any binaries, and do general setup correctly.
Related
Firstly , i would like to say that this package is amazing in the sense where there can be so much flexibility. Im relatively new to this package and im just trying to figure a way to fiddle around with the provided front end in the river-admin package. Could someone point me in the correct direction in doing so?
I am the author of both django-river and river-admin.
river-admin is an admin interface for django-river implemented as a Vue.js application backed by django-rest-framework.
One fact about it is that it was never meant to use the river-admin as an extension to your django app which means that it doesn't have to fit in how your own django app looks. You might think of it is like the UI of Apache Airflow or RabbitMQ admin interface and so on.
But if you think that the things you wanna add are something that can be used by all of its other users why not contribute to the repo. Otherwise, you can always fork the repo and do the custom changes that you can not do via the river-admin API, build the package by yourself.
Here is some information on how one can build and run stuff locally
I've built out a basic django application, and I'm looking to incorporate react+redux into the app. I've come across several react+redux templates like the react-redux-starter-kit and redux-webpack-es6-boilerplate:
These are awesome, except they both run node servers. I'm wondering:
Does there exist some sort of a tutorial or template that has the same features (webpack, Hot Module Replacement, linting, testing, abides by Fractal Project Structure guidelines, etc...) but does not run a node server, so I can just copy it into my django application (I realize I'd have to do a fair bit of configuration to get everything working smoothly).
Is it ok to run the webpack server within my django application? (Basically node would be running within django) Are there any downsides in doing this?
I've tried altering the above two templates, but they are pretty dense and complicated. Any advice would be very much appreciated!
I don't see any reason to mixing up django and react app.
I would prever leave them as two independent parts of your application: SPA (react + redux) + API (django)
If you already have django app and just need to add some react pages into, then build react app as static files and place it outside your django project, and configure your reverse proxy server (nginx) to load those new pages as static pages (react).
I've downloaded Ember.js ver 1.13.13 for a test drive.
With other js frameworks, I am able to run from a file system. Does Ember require a server? I could not run directly from a file system. I did find some old tutorials that allows this. Is this a new thing?
You are using Ember-CLI which requires running ember serve in order to view your ember app. Ember-CLI uses conventions so that it knows where to locate the files that compose your ember app. As Ember-CLI locates your files, it knows how to combine them in a manner that ultimately results in the single JavaScript file that is executed in your browser. In theory you could use the globals style of development-which is the style reflected in the 'old tutorials' that you reference-and run the app directly without using any sort of "server." But, I don't recommend that. Learning Ember-CLI is useful as it is the preferred method of development moving forward. And, in my opinion, gives you a number of features that allow you to more quickly prototype apps. You can read more about that in the link I provided to the Ember-CLI website.
I would like to avoid to manage a big index.html file containing all my handlebars template.
I read multiple blogs with different solutions but I'm not sure of the best one.
Is there someone from the official ember.js team able to provide the best practice for this ?
Is grunt the best solution ?
Currently I do not use any special backend like node.js. Only a basic http apache server. The REST API is provided by a Tomcat server
IMO if you are not a rails developer then one of the best option would be indeed grunt or much better yeoman (http://yeoman.io/). Using the generator-ember (https://github.com/yeoman/generator-ember) and yeoman togheter will get you up and running in no time. For example after installing yeoman and the generator-ember you can create a full project structure with a simple yo ember, this will create all the necessary folder for views/controller/routes/templates where you can start coding right away. You should give it a try.
Edit
As stated in the comment of #Toran Billups, the ember core team is working on this project (https://github.com/stefanpenner/ember-app-kit) which will be grunt based and it will work using modules and much more awesome stuff.
Hope it helps.
In Java world, a common way to distribute a web app is to package it along with Apache Tomcat.
What is the appropriate way to achieve something like that with Django (or any WSGI application for that matter)?
There are two camps for distributing apps in django. It also depends on what you mean by apps.
If you mean an apps is in django terms as in 'pluggable apps' that is separated from the project, then it would be best to use setuptools to package those 'pluggable apps'. Many django 'pluggable apps' are distributed like this. For example:
django-tagging
django-registration
etc.
But if you mean an apps is a full-blown apps (the whole war file) as in Java EE terms, then you would have all off your apps inside a your project, and you would just distribute the project in any forms. Normally you would just zip it. You don't need to install it with setuptools or what so ever, as you would run your project from the project folder. Examples in this camps are:
Pinax
Satchmo
The first way is convenient if you already have django project running and you want to re-use those pluggable apps in many other projects. This is really good if you are building non-monolithic web application or an in-house application/websites or a reusable application . It's also convenient if you are managing your project and those pluggable apps by yourself. It's sort of inconvenient (to some extent) if you want to sell an apps to a customer with this kind of approach because your project and your pluggable apps lives in a different directories. Some people said that they don't have any issues with this approach.
The second way would be more convenient if you are selling your apps to a client because all of the apps is inside your project and you would only extract your project when you are at the client side. This style is more often called the monolithic style. Java EE and Ruby on Rails have a monolithic deployment style. You wouldn't need to install your 'pluggable apps' one by one (assuming you don't use any external pluggable apps in your project) when you are at the client side. But again, you would have some issues if you want to reuse those small apps inside the projects. If you don't have any plan to re-use those small apps, then this way is good enough.
setuptools is a common way to distribute any Python packages, Django apps included, and many of the more substantial Django apps (Pinax comes to mind) will either distribute through the cheeseshop or as tarballs or zips with setuptools-produced setup.py files.
Less substantial reusable apps will just distribute as compressed files, which works fine as they should be highly portable.
A django app is not much different from a python module, which you can package using python's setuptools.