How to develop a CRM system from scratch from an architectural point of view?

Question

JavaScript

Friends, hello :) Some business needs a completely custom CRM system that includes some basic things (accounting, information on LEADs, income statistics from links to the site, orders from the site and the process of their implementation, salary calculations for employees), as well as special things (tracking delivery vehicles, authorization of the manager involved in the order). The client wants to store everything in the cloud, and we plan to use node.js / python (flask) as an implementation tool. DB - mongo. There were a lot of questions due to inexperience:
1) How correct was the decision to use node.js and mongo?
2) If we store data in the cloud, then where do we store the application itself? How do we access it (by url?) ?
3) The company has a lot of sites, most of which are landing pages on pure html with a php script for mail. All orders refer to a single gmail box. Is it possible to rob this data from the box to send it to the cloud?
4) What are some convenient cloud services that provide an API for node.js?
5) What is the approximate cost of such a project in $?
Thank you very much in advance! Have a nice day, everyone.

Answer 1

1) How correct was the decision to use node.js and mongo?

The question is largely tricky. CRM is, by definition, a lot of relational data. Storing this in any nosql - I personally think it's a very bad idea. Especially when change requests come in half a year and it turns out that things that are done in relational in a couple of minutes in nosql may require changing the storage architecture and take man-weeks.
Can. But taking into account the fact that email delivery is generally not guaranteed - to tie one of the key business processes to this looks, to put it mildly, strange. For good - make an API in your CRM for ordering and rewrite all sites to work with it.
* It is strange that your programmer cannot answer this question with his eyes closed
I would venture to suggest that the decision maker somewhere heard about the clouds and he liked it. In all seriousness, giving all business content to an external service is either a complete idealist, or simply not understanding what it is about. Only their iron servers, only physical redundancy.
Depending on where you are, how legally you make out all this
. In Moscow time, a decent developer can now be found for 100-120 tr. net, in the regions for 40-60 net (depending on the region).
How many of them you need - it's unrealistic to say without technical specifications, but I think that the estimate from below is 3-4 developers
+ team leader 100% + project manager 100% + analyst at the start + designer at will + devops on outsourcing, etc.
PS No offense, but look for a competent CTO who it organizes everything. In any case, this is a long project, so it is possible to find a person on the staff.

Answer 2

I can't answer all questions, but in my opinion, if you use python, take django. It is more intended for large projects.
Node.js - more focused on microservice architecture. If you know how to cook it, then for God's sake, but I think you should not do it entirely on the node. Mongo should only be used if you really understand the difference between an RDBMS and mongo.
3) I don't think it's a problem.
4) API for cloud servers - what difference does it make what language it will be? Is that the presence of an already prepared .
5) More than 1 million for sure.

Answer 3

Before choosing "on what", you need to understand "how"!
Dependencies of roles and their various parameters among themselves are necessary.
Those. the scheme of interaction of flows of business objects and then - the database scheme (based on it).
Каналы, компании, клиенты, активности, линки, переходы и т.д. вот всё это - объектные роли.

Answer 4

1) На сколько верным было решением использовать node.js и mongo?
As far as you know them.
The cloud stores both the data and the services themselves for accessing the data.
Access - as usual - either through a web interface or through a RESTful API.
Yes.
Enable IMAP access there.
heroku.
https://habrahabr.ru/sandbox/69602/
It also happens differently. Sometimes sharpened narrowly. It happens to be universal. There are many opportunities, there are few opportunities. It happens that the word "cloud" is understood differently (it seems that they use the cloud, but they squeeze money for additional instances).
I participated in the development of such a system. Just cloudy.
10 developers * 6 months * $4,000 per person - alpha version.
3 more months - beta version.
Another month - pre-release.
Total 10*(6+3+1)*4000 = 400,000 USD and 10 months just to go to pre-release
Developers I mean - backend, frontend, project manager, devops.
Pure developers 8 people.

Answer 5

Taking a database without transactions when working with finances threatens with terrible hemorrhoids (emulating them in mongo, still not a cake)

Answer 6

3) make a request handler from the site on the CRM php side. Applications immediately in CRM will "fall"

Answer 7

to develop it yourself - stupid
database - only RDBMs are the
main hemorrhoids in CRM - final accounting of money - their coincidence with real ones, logging of all actions on balances, etc.