Ask HN: If you were to build a CRM today what would your stack be?
In terms of learning new things, trusting that it's secure production ready, and bootstrapping when possible. React seems interesting, but it requires a lot more additional components as you only seem to get the view. I've used RoR before but for something like this performance could be an issue. The good thing with rails though it has basically everything needed with plenty of scaffolding. Angular is a monster and that at least would give the entire MVC but seems to be on the decline and is not a friendly framework.
I've had other posts where I'm trying to find a good CRM, and have come to the conclusion that some will get me close but ideally building a bespoke version would give me full control and be able to add whatever features I want without arbitrary limits. Additionally, since it's a larger undertaking compared to previous projects a lot of experience could come from it.
79 comments
[ 3.0 ms ] story [ 148 ms ] thread[0] https://github.com/reactjs/react-rails
(This year it looks like it'll go to Java though, so :P)
http://www.tiobe.com/tiobe-index/
Any stack will get the job done. Use the one that yields you a shippable product in the end.
My stack is ExpressJS, AngularJS, PostgreSQL, NGINX, DigitalOcean, Route53, PM2. And I fly through it.
On the backend, ASP.Net core is looking good to me. Although, Go and Elixir are picking up fast. Heck, ignore the haters and use Node if you want.
Finally, don't be scared to use something "old" like Java (EE or Spring) or even Rails (personally, I believe the whole performance fiasco is not as bad as you would think)
For our team that would be Node.js with a React frontend, with probably MongoDB as the database, but every team is different.
As a side note: APIs are very important for CRMs, but as long as you design your API well you can swap out, move around, and refactor your backend as it makes sense.
Performance wise it has always treated me well. It also provides a lot of power over updating partial documents (push this item to a sub array, remove this item from another subarray, at this item but only if it doesn't exist, etc)
Both of those are usually "belongs to" relationships. That kind of relationship is easy to model in NoSQL. Many to many becomes difficult but in those scenarios I'd recommend either a relational or a graph database (also NoSQL) like Neo4j or Orient.
If the only thing you have is NoSQL everything looks like a document?
Because the document model allows an arbitrary number of columns I think in this case it would make adding custom attributes to leads in an easier to manage way than using the traditional join with attributes table method.
I think a relational model may be a bit overkill in this case. But with that said, I'm sure it can easily be done with traditional relational DBs as well.
I've also used Elastic for similar projects to because it's ability to do faceted filters on data is unparalleled IMHO.
Applications like Salesforce and MS Dynamics CRM are pretty much platforms for building applications as much as CRM applications - indeed in both cases you can license them in ways where you get the flexibility of the platform without access to the standard CRM entities.
I've built the framework to a CRM (Python and Flask) and I wonder how it'd line up with your needs. I'm not currently using it, as it needs a bit more work, but I'd love to talk to you about your project.
If latter, I would probably choose vuejs/Play2/MongoDB. (Replace Play2 with RoR or Django or anything else).
Front end: We use Ember because of its balanced focus on progress and stability. The team behind it is solid and batteries are included.
Application: Ruby/Rails, Elixir/Phoenix. Rails is great for getting up and running quickly, and your problems with #scale won't be on the application later. Elixir (really Erlang's BEAM) is great at quickly spinning up/down lightweight processes that handle raw data. So if you want to build a CRM and, say, manage emails, then it could be a good fit. Or if you want to process a 1,000,000 row CSV import, etc.
Database: Postgres. Binary JSON columns give you flexibility, plus PostGIS for all of your geospatial needs. Structure as much as possible to take advantage of the smart people who have spent countless hours building a world class database. You'll appreciate their focus on correctness.
My overarching advice: push everything as far down the stack as possible. If you can do it in Postgres, do so. Data correctness is your life; better that your DB throws a fit than your application serving bogus data.
Happy to answer any specific questions!
(And I wouldn't be a YC CEO if I didn't take the opportunity to mention that we're hiring! http://seneca.systems/careers)
@Tyre: we use React on the front end but have struggled with meeting customer's UI expectations for Master/Detail displays of tabular data... the mobile UI design paradigms on this are so rich, are there any best practices for web UI?
Thanks!
NB Mind you - I can definitely see the advantages of using JSON but a lot of developers seem to resist dynamically altering relational database structures when it can actually work pretty well.
What expectations are you having trouble with?
As for mobile, I wouldn't try to have it do everything that the desktop version does. It's just not possible, at least not well, with that size screen and type of input.
Sorry, this is heading off topic for the OP, but interesting to note the priority of your first hire -- smart choice!
[0] http://cx.codaxy.com
Yep you're right, most of these are essentially putting a UI on a database and that part has to be right - otherwise you have much bigger problems.
Hah, well if things don't exactly work out I'll have http://seneca.systems/careers/product/front-end-engineer bookmarked.
I'm not sure how universal it is for CRM systems to be all about who knows whom, from where and what's the nature of the relationship, but the ones I've been involved with certainly all were.
A CRM is typically a form based app doing CRUD - to be this makes it a solid candidate for being a stateless client.
I feel like there's a whole class of applications out there now (including my own) that have gone down the stateful client route where it wasn't necessary and introduce a whole new set of problems and solution libraries / frameworks that can be forgotten about with a return to a stateless arch.
For building a prototype CRM system, a server side CRUD-oriented system is going to be the fastest. You could probably build an impressive prototype in Rails (or similar) pretty quickly.
But as the system starts to scale, you'll end up having to extract performance improvements either by optimizing the "within request" performance (caching, etc.) or by creating a hybrid system that uses some client side code to do lightweight updates to a server-rendered page. This is where complexity creep comes in and where may projects start to die and become unmaintainable.
I think many application building decisions are optimized around the early win of easy crud or easy data grids. Even in an app that is full of these things, it does not always make sense to choose the easiest solution.
Instead, figure out how often data changes. If most data changes rarely, as in a CRM system, data can be relatively lazily cached on the client.
Obviously a lot depends on what CRM app you are building, who is using it, how long you expect them to use it, whether it's going to be used on mobile or slow clients, etc.
Edit: looking at what you already considered, maybe: back end: Ruby, front end: VueJS
If you're a profitable company with a sizeable userbase, just buy Salesforce. It's clunky, it's expensive, but you can find contractors really easily to make it do whatever it is you want. Or you can learn the Salesforce platform yourself and build your final CRM on top of that. Welcome to enterprise IT!
If you're a scrappy start-up, or non-profit, with a small number of people to serve, you can use whatever you're most comfortable with. A single database (perhaps with hot replica,) a single application server (perhaps with load balancing for good measure) and you have everything you need. Use whatever you already know. PHP and Bootstrap? Ruby and Rails? Node and Angular? Doesn't matter.
If I were in the middle area -- successful company, lots of customers, but not actually at the point where I need the Salesforce behind-covering and easy contractor access -- then I would probably use React for the front-end GUI, and Haskell with Warp for the back-end services, hosted on top of MySQL or Postgres, with Redis for data caching, plus some scripts to make creating bread-and-butter tables/indices/queries simpler and less repetitive. Like the poster above, I kind of like having an "escape column" for "annottation data" stored in JSON, although it can simply be a plain TEXT. As long as you don't need indexing, it makes adding new columns easy even if you have a table that's too big to change online.
Although there are a lot of different tech stacks, I think that most of this boils down to SPA vs integrated views with some javascript. In the rails world, this generally means either Rails plus jQuery, unobtrusive javascript, coffee script, and so forth, vs rails-api and Ember (or another javascript front-end).
Right now, I lean more toward the integrated views than most of my fellow developers. Very few people would take an always/never position on single page apps, so this generally boils down more to how far people want to take them. Some are more eager to apply them in a wider range of scenarios than others.
I personally lean toward the integrated view approach, and I advice caution around SPAs - in my opinion, very much an opinion here, I think they add a lot of complexity compared to the integrated approach, and are still in a state of flux. If what you are writing really is mainly a set of forms that you'd like to enhance a bit with automatic page refreshes, drop downs, drag and drop elements, autofill and so forth, you may want to stick with a more stable stack that isn't evolving as rapidly as SPA javascript frameworks.
There are situations where you can find yourself in a real mess with an integrated view, that would be far easier to manage with Ember or another javascript framework, keeping your backend logic in a relatively simple API. Not sure if that's going to happen in a CRM - they tend to be pretty form-ish apps, but perhaps that's because up to now, difficulties with javascript have led us to think of them that way. The rapid evolution of JS frameworks may, for all I know, have opened up an opportunity for serious innovation here.
One other thing - remember that it is relatively easy to expose a rails method as an API even in the absence of rails-api. My guess is that this is true of most integrated frameworks that provide a view tier. You won't be locked into an integrated app provided you keep logic out of those views! You should be doing that anyway. Also, make sure your tests don't rely exclusively on the views to verify logic that isn't in the view (again, you shouldn't be doing this, but I've seen it a-plenty). That'll keep you flexible enough to transition away should you want to at a later date.
Good luck!
I've been dealing with different CRMs recently (SFDC, Netsuite, MS Dynamics, AgileCRM) and I don't think tools really matter, architecture that will allow you to customize everything is the key for CRM
As my personal choice it would be (I'm a full-time Python dev)
* Java/C# (there's nothing really dynamic in crm, entities, fields, etc with different "name" and "display_name" for each customer, IDE would allow me to manage complexity)
* PostgreSQL (no NoSQL, CRM is all about relations)
* Vue.js
* ElasticSearch (with Kafka for replication from db)
* RabbitMQ for offline jobs
2. ReactJS
3. Foundation for Rails
4. MySQL
This is literally everything you need to get it off the ground as soon as possible.
This is what has helped me build Allt.in (https://allt.in) and UnderstandBetter (https://understandbetter.co/)
Starcounter (http://starcounter.com) is an in-memory application platform, which is comprised of an in-memory database (ACID-compliant) with a built-in app server.
You can compose a complex business system out of small apps (micro apps if you will). Apps don't pull the data from the db - they run in the db. Multiple apps that run in the same db share the data in real time. Our first clients are retail, CRM and advertising tech.
From dev perspective, we like to call our approach "collapsing the stack". There is no ORM. Your code classes become the database tables. You can use our (Web Components based) approach to create thin client HTML views that bind to the data using JSON Patch. This saves you from running huge amounts of glue code, which is typical for traditional software stacks.
Right now we are on Windows/C#. Linux and macOS is coming next year. Other languages will follow.