Ask HN: If you were to build a CRM today what would your stack be?
79 comments
Hi! We're building a CRM for local governments (https://romuluscrm.com), in 2016, so I can tell you what we do.
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)
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)
+1 For Postgres with Binary JSON, when that feature was added a few years ago it completed changed the value prop in how we respond to customer requests (them: "can you please add two extra fields for fax numbers?" us: "who needs two fax numbers?")
@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!
@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!
Quite a few applications (e.g. Dynamics CRM) dynamically create database columns when fields are added at the application layer - works pretty well and create a relatively clean relational data model.
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.
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.
Our first hire on the product side was a UX/Product designer specifically for this reason. CRMs are incredibly complex and making it easy to use is a real challenge.
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.
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.
The point I was trying to make about mobile is that "master/detail" patterns are well established and the UX clear (cf. Android & iOS default address book apps); this is not the case on the web. Each of SFDC, SugarCRM, Insightly (and presumably Romulus) uses a different pattern. And if you look at front-end frameworks for guidance (Bootstrap, Foundation, cx_codaxy [0]) most don't do more that provide data tables with in-line edit; rather tedious for CRM with several dozen fields. We try to use UX analysis tools and interview users (Inspectlet, UserTesting) but we still sense a lot of frustration & confusion...
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
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
This response is exactly what I was looking for. Absolutely love the breakdown. I looked at Ember awhile back for a different project, and it seemed really robust (more than what I needed then!) but for this I think you guys made a solid choice. I'm also a big fan of Postgres so this stack wouldn't be too scary to embark on.
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.
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.
[deleted]
Your pricing mentions case management but I can't find an explanation anywhere what erm... case management even is. Sorry I'm not in govt, just curious.
This page has more info about case management in Romulus: https://www.romuluscrm.com/centralize.html
The stack is probably the least of your problems. A CRM usually needs to be highly customization so picking an architecture that allows for customization while still being maintainable sounds like the real problem. You can get this right or mess it up with most stacks.
This is exactly right. Who cares about the stack? Start by building a platform to build more applications. Then, build a basic CRM app on top of your platform, then provide a way for customizing it, then provide a way to make sure that customizations survive all updates, even when the underlying platform/application change.
Hard to know until you've done it. You could end up with Drupal when all you needed was WordPress.
Yeah - I guess the hope is that you end up with the next generations of force.com that doesn't require APEX.
Oh? Why do CRMs need customization? In what ways, do you think?
The sales and customer services parts of organisations are often pretty fluid - lots of requests to add new fields to collect new bits of data and there is often a lot of pressure to get these changes done yesterday.
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.
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.
Interesting! I wonder if there is a market for kind-of a simple CRM: but then I suppose you'd be selling the method, not the software.
I have worked in this space for a while and the typical users of CRMs won't accept a standard method. If you come up with a method that works for all companies you can go into sales training, write a book and become rich beyond your imagination :-). Skip the writing software part because that will be easy.
Do you mind sharing where you work and would you be free for a phone call to give me some advice on a product?
I'm sure!
Well, as a minimum, you might want to be able to customise the fields that define an entity, the relationship between different entities, and the workflows and processes that those entities may use to interact with one another.
I'm just starting a CMS project, which is going to be my first big project. I've done a lot of research, read a lot of material on almost every framework possible, I wanted to make sure I would do the right choice both for my self (ease of use, enjoyable to work with, productive), and the buisness (long term maintainability is the most important thing).
I've gone over Angular 2, React, Vue.js, Ember, Polymer, and so many more. The one I really connected with is Vue. While I realize it's only been gaining popularity in recent months, there are some big companies who start to make use of it in big scale production sites (Alibaba, Laraval, ...), this makes me pretty confident that support will not be an issue.
For the db I would definitely choose Postgres, but I would go for plain old relational tables, and maybe use its JSON features for data which is isolated and does not relate to other data (e.g.saving spreadsheets data).
For the server I would choose NodeJS + Express + SequelizeJS, and I will probably make use of some GraphQL library up ahead too. But honestly, if you choose to make your system a SPA, then your server will not do much of the heavy lifting anyways - it will probably expose an API point and be used as an interface to the database, so I think any back-end stack would fit in. I would also consider Python + Flask + SQLAlchemy, which used to be my stack of choice few years back.
I've gone over Angular 2, React, Vue.js, Ember, Polymer, and so many more. The one I really connected with is Vue. While I realize it's only been gaining popularity in recent months, there are some big companies who start to make use of it in big scale production sites (Alibaba, Laraval, ...), this makes me pretty confident that support will not be an issue.
For the db I would definitely choose Postgres, but I would go for plain old relational tables, and maybe use its JSON features for data which is isolated and does not relate to other data (e.g.saving spreadsheets data).
For the server I would choose NodeJS + Express + SequelizeJS, and I will probably make use of some GraphQL library up ahead too. But honestly, if you choose to make your system a SPA, then your server will not do much of the heavy lifting anyways - it will probably expose an API point and be used as an interface to the database, so I think any back-end stack would fit in. I would also consider Python + Flask + SQLAlchemy, which used to be my stack of choice few years back.
I recently (for the last 3-4 months) attempted to code a CMS as a side project. I've chosen Python+Flask+SQL and vanilla JS, but have considered using Node and Go at various times of my coding.
The biggest disappointment I had by not using Node is that I couldn't easily integrate all the beautiful javascript libraries by just loading a module from npm.
For example, I'm using Quilljs for text entry, and I have to write something that parses Quill's JSON output and turns it into a renderable html/markdown. If I had used Node, there is already a module for it :).
If I started from scratch, I would have designed the back-end first without using any library. (I would define my objects User, Post etc. and hid the SQL as methods (e.g create, update, delete) under the hood) That way, I could debug the app, add new features without having the need to setup a web server. I could also write sound unit tests. I seriously regret not having done that.
The problem with my CMS was, that it was easy at the beginning. My customers asked new features and I just hacked them in. Now, my code is still legible, but since I've used wrong abstractions, it's a pain to add new features.
Your mileage may vary, I was inexperienced with FLASK and SQL at the time I started the CMS. I've learned a lot during the making and wanted to share my two cents.
The biggest disappointment I had by not using Node is that I couldn't easily integrate all the beautiful javascript libraries by just loading a module from npm.
For example, I'm using Quilljs for text entry, and I have to write something that parses Quill's JSON output and turns it into a renderable html/markdown. If I had used Node, there is already a module for it :).
If I started from scratch, I would have designed the back-end first without using any library. (I would define my objects User, Post etc. and hid the SQL as methods (e.g create, update, delete) under the hood) That way, I could debug the app, add new features without having the need to setup a web server. I could also write sound unit tests. I seriously regret not having done that.
The problem with my CMS was, that it was easy at the beginning. My customers asked new features and I just hacked them in. Now, my code is still legible, but since I've used wrong abstractions, it's a pain to add new features.
Your mileage may vary, I was inexperienced with FLASK and SQL at the time I started the CMS. I've learned a lot during the making and wanted to share my two cents.
I'd recommend you to watch this talk https://www.infoq.com/presentations/SalesForce-Multi-Tenant-...
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
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
I always go with the stack that I'm most comfortable with, unless I'm using an existing stack at a company I'm working for. Learning a new stack because it's "popular" is a recipe for disaster if you're incorporating into a product you want to use or want to charge others to use. You'll spend time trying to figure out how to do things that you already know how to do in another stack.
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.
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.
Given that major companies have been built on what was not seen as cutting-edge stacks at the time of conception -- Facebook on PHP, Github on Rails -- maybe Rails could still be the sensible choice? RoR might itself not be fast, but on the upside, its community seems to be pretty forward-facing in building plugins for client-side tech, i.e react-rails [0]
[0] https://github.com/reactjs/react-rails
[0] https://github.com/reactjs/react-rails
Although they may not have been cutting edge, they were pretty hot: Facebook was started in 2004, when PHP won the TIOBE 'Programming Language of the Year' award, and GitHub in 2008, two years after Ruby won it (although I'd say 2010 was the most popular year for Ruby on Rails).
(This year it looks like it'll go to Java though, so :P)
http://www.tiobe.com/tiobe-index/
(This year it looks like it'll go to Java though, so :P)
http://www.tiobe.com/tiobe-index/
[deleted]
Whatever one gets you to market the fastest with the features you need. Which is usually "what your team is most comfortable with"
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.
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.
Can you share your rationale for choosing MongoDB?
Being a NoSQL database I think it would lend itself well to a CRM if you look at each lead as a document.
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)
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)
Agents to Cases to Leads to Contacts to Sales to Organizations seems super relational to me. Maybe you'd want some extra-schematic info in the form of a serialized column on each table, but that's about as far as I think you'd want to go.
:delayed response:
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.
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.
> I think it would lend itself well to a CRM if you look at each lead as a document.
If the only thing you have is NoSQL everything looks like a document?
If the only thing you have is NoSQL everything looks like a document?
Not true, in my case at least. I often use relational database. It depends on the use case.
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.
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.
Why does it need a client-side framework? There's a class of apps where that makes sense, but it feels like more and more that's becoming a default at the expense of complexity and time to market.
For some kinds of state management, client side is way easier to reason about and the abstractions one ends up with make a lot more sense. CRM is likely in this category.
Can you please elaborate on how a CRM is likely to be in a category where it would benefit from state heavy client-side?
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.
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.
I would love to know the answer to this too.
Apologies for my brief and unsupported assertion. My take is as follows, surely many people would disagree.
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.
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.
I'm building a personal CRM to help me manage my personal relationships (https://simplerm.co)
Stack is two separately hosted apps.
Frontend: react, redux, webpack as a single page app Backend: Rails for an API
Why? I wanted to learn react and redux and I like using Rails for my backend and was comfortable with that.
Stack is two separately hosted apps.
Frontend: react, redux, webpack as a single page app Backend: Rails for an API
Why? I wanted to learn react and redux and I like using Rails for my backend and was comfortable with that.
We used Scala, AngularJS and PostgreSQL.
Actually except AngularJS we are really really happy. Everything is fast and the development speed is ridicoulus, especially calculations and performing operations on big lists are extremly good in Scala.
Actually we are probably introducing Redis (actually we use Akka-Cluster for PubSub) however we think that with Redis we can even be faster and Cache our stuff better.
For our JavaScript stack we will also look into ScalaJS and/or Vue.JS, React and Ember, but at the end we probably handroll our own at this stage, since our feature set is really different from what these provide (we don't need any mobile stuff, really...), at the moment we have zero mobile clients and we looking to build an app for a small inventory service, but thats all.
For our JavaScript stack we will also look into ScalaJS and/or Vue.JS, React and Ember, but at the end we probably handroll our own at this stage, since our feature set is really different from what these provide (we don't need any mobile stuff, really...), at the moment we have zero mobile clients and we looking to build an app for a small inventory service, but thats all.
What problems did you run into with Angular?
no problems, but actually we started using angular pre 1.0 and a lot of things are just messy right now, we have lots of different ways how to define a controller and the upgrade path is extremly bad for us also since we are coming from Scala we feel the pain of the lacking type system (typescript would of course resolve that, however we don't want to hook ourself again in the claws of google, we gone trough GWT to Angular already).
If you want to be super successful, you build it on Salesforce. Full stop. Two - two! - different vertical CRMs (ServiceMax and Veeva) have BILLION dollar valuations built entirely on the SFDC stack.
It'll answer all technical questions, make it easier to hire, and make it easier to fundraise. Oh! And easier to get customers.
Then think about how people get info into your system - if its email, use Nylas (it's gonna be email to start). If it's voice, use Twilio. If it's directly, then abstract all the complexity and use the right terms for your market.
I don't work for Salesforce, I never have in the past, and I barely use it now. But choosing anything else is nuts.
It'll answer all technical questions, make it easier to hire, and make it easier to fundraise. Oh! And easier to get customers.
Then think about how people get info into your system - if its email, use Nylas (it's gonna be email to start). If it's voice, use Twilio. If it's directly, then abstract all the complexity and use the right terms for your market.
I don't work for Salesforce, I never have in the past, and I barely use it now. But choosing anything else is nuts.
We've basically done this and in most ways it's certainly true, but it's also incredibly inflexible and slow to develop. Apex and Salesforce's platform limitations are a nightmare. Nearly everyone contracting in this space delivers a shitty end-product and it's difficult to hire full-time developers to do Salesforce because they all want to contract (it's so lucrative!). You will sink a lot of cost into training developers on the platform and then risk them leaving you to do contracting.
And if you run a 24/7 business or for any reason can't shut down your CRM for 8+ hours ever, god help you if you ever need to do something to modify millions of records like ETL. I have about 2 weeks of concurrent sleepless nights I can blame entirely on Salesforce.
Also, I hope you have deep pockets.
And if you run a 24/7 business or for any reason can't shut down your CRM for 8+ hours ever, god help you if you ever need to do something to modify millions of records like ETL. I have about 2 weeks of concurrent sleepless nights I can blame entirely on Salesforce.
Also, I hope you have deep pockets.
The question is: Solving what problems, at what scale?
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.
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.
Given that the bread and butter of CRM is lots and lots of CRUD ui, often showing the same data organized different ways, I'd immediately do a spike on using relay/graphql along with your team's preferred backend technologies. I haven't built an application this way yet so I'd love feedback from anyone who has. My assumption is that investing the effort in getting graphql going would pay dividends.
I'm building a front-end stack at the moment as a private project.
The main parts are:
- type safety, in the hope that it speeds up development. TypeScript 2 is my main contender here.
- on demand module loading, so I can shrink the initial page loads, will go with Webpack 2, because it lets me use System.import() and automatically splits these imports into it's own files
- interaction flow control completely based on observables, because they compose nicely and with genertic types ease development quite a bit. Will go for Cycle.js (+xstream), because it's rather tiny and really everything there is an observable, data and UI, also it's written in TypeScript. Feels a bit like Angular2-lite.
- WebComponents based UI-widgets, because I think they should be independent from the rest of the application, don't know yet if I'd go for Skate.js or Polymer, maybe I'd even use custom components directly. But I like the Skate API much more than Polymer or the "native" API.
- data retrieval will be based on GraphQL with the hope that it will lower data-on-the-wire if the client has more control on that. I also hope that the GraphQL subscriptions (based on WebSockets) will integrate nicely with the observables. Apollo-Client is my fav here, it's framework independent and written in TypeScript, too. I'll probably use their GraphQL-server, too.
Every part is pretty much independent of each other (besides everything being written in TypeScript, haha) so I think I can use parts of it in future projects.
Server side rendering would be a nice to have, because it would enable the basic app functions on clients without JavaScript.
The main parts are:
- type safety, in the hope that it speeds up development. TypeScript 2 is my main contender here.
- on demand module loading, so I can shrink the initial page loads, will go with Webpack 2, because it lets me use System.import() and automatically splits these imports into it's own files
- interaction flow control completely based on observables, because they compose nicely and with genertic types ease development quite a bit. Will go for Cycle.js (+xstream), because it's rather tiny and really everything there is an observable, data and UI, also it's written in TypeScript. Feels a bit like Angular2-lite.
- WebComponents based UI-widgets, because I think they should be independent from the rest of the application, don't know yet if I'd go for Skate.js or Polymer, maybe I'd even use custom components directly. But I like the Skate API much more than Polymer or the "native" API.
- data retrieval will be based on GraphQL with the hope that it will lower data-on-the-wire if the client has more control on that. I also hope that the GraphQL subscriptions (based on WebSockets) will integrate nicely with the observables. Apollo-Client is my fav here, it's framework independent and written in TypeScript, too. I'll probably use their GraphQL-server, too.
Every part is pretty much independent of each other (besides everything being written in TypeScript, haha) so I think I can use parts of it in future projects.
Server side rendering would be a nice to have, because it would enable the basic app functions on clients without JavaScript.
> I've used RoR before but for something like this performance could be an issue.
We should speak about numbers, Rails would handle any normal app without problems. I'm not a huge Rails fan but I know that its image is broken and everyone claims that's it's slow just because someone who really needed performance ( Twitter, Github etc.. ) said so.
We really should differ between 'normal apps' and huge apps.
So basically, Rails is totally fine for your project.
> 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.
We are talking about angular1 ? If so, I don't think it's declining, I actually believe that lots of established companies would not start a project with angular2, simply because it just got released.
Angular1 is fine, I know quite a few people who started their projects 1-2 months ago using angular1, the only difference is now, that they try to keep it modular, for example they stay close to the recommended way of doing things, which makes upgrading to angular2 easier, they refer to the John Papa guide[0].
Because you asked which stack we would use:
I'd use the Play! Framework or Spring Boot, since there is more CRUD I'd probably use Spring boot, VueJs because I would not create a SPA but would extend functionality with some lightweight frontend framework, angular1 is too big, Vue seems right.
Postgresql, because Postgresql.
[0] https://github.com/johnpapa/angular-styleguide
We should speak about numbers, Rails would handle any normal app without problems. I'm not a huge Rails fan but I know that its image is broken and everyone claims that's it's slow just because someone who really needed performance ( Twitter, Github etc.. ) said so.
We really should differ between 'normal apps' and huge apps.
So basically, Rails is totally fine for your project.
> 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.
We are talking about angular1 ? If so, I don't think it's declining, I actually believe that lots of established companies would not start a project with angular2, simply because it just got released.
Angular1 is fine, I know quite a few people who started their projects 1-2 months ago using angular1, the only difference is now, that they try to keep it modular, for example they stay close to the recommended way of doing things, which makes upgrading to angular2 easier, they refer to the John Papa guide[0].
Because you asked which stack we would use:
I'd use the Play! Framework or Spring Boot, since there is more CRUD I'd probably use Spring boot, VueJs because I would not create a SPA but would extend functionality with some lightweight frontend framework, angular1 is too big, Vue seems right.
Postgresql, because Postgresql.
[0] https://github.com/johnpapa/angular-styleguide
This is a big question on everyone's mind right now. "What stack should I use" is always a big question, but sometimes web development goes through a particularly notable state of uncertainty.
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!
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!
For a CRM the database is probably more important than the programming language / framework.
Depends on whether or not it will be a SaaS or self-hosted. If it's the former, stack doesn't matter. Just use whatever you're most productive in. If it's the latter, I'd go for something very easy to deploy. PHP, despite it's shortcomings (speaking as a long-time PHP developer here), is very very easy to deploy and PHP7 really doesn't suck. RoR is also a reasonably good choice, as a lot of shared hosts run it with Passenger (or whatever the tech is), so end users can just upload the files and not mess with server config or anything.
It seems your looking for something A) Simple but powerful, B) scalable
This is all my opinion, but I would take a chance to try out Vue.Js on the frontend. If you want to learn something a little different, Elm looks cool too.
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)
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)
Why would a CMS need to scale? At most you'll probably have a few tens of admin users logged in concurrently, and a few million people viewing pages that could be baked in to static HTML assets if scaling is a priority. An AWS micro instance and an S3 bucket would handle that.
First off, we are discussing a CRM not a CMS and secondly, he said no to Rails for perf reasons.
If you want a specific CRM solution for your company, anything that your are comfortable with is fine. If you want to make it a platform, and a generic CRM solution that other companies can use, you need to think about APIs, security, customizations (custom entities, custom fields, relations, customizing UI), multitenancy (if you want a hosted solution). The list goes on.
If latter, I would probably choose vuejs/Play2/MongoDB. (Replace Play2 with RoR or Django or anything else).
If latter, I would probably choose vuejs/Play2/MongoDB. (Replace Play2 with RoR or Django or anything else).
1. Ruby on Rails
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/)
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/)
Angular 2 or React front end, Scala / Play Framework 2 / Postgres backend for some serious scalability.
Shameless plug (I am one of the devs):
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.
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.
Whatever you choose: for a CRM it's great to separate front end from the back end. So build a very good (REST) API, because CRMs tend to be connected to a lot of other systems.
Edit: looking at what you already considered, maybe: back end: Ruby, front end: VueJS
Edit: looking at what you already considered, maybe: back end: Ruby, front end: VueJS
I've used Vue before and it's one of those that I would love to build a project around because like rails, the first time you use it the language seems really magical, intuitive, and easy to write. The way it handled two-way binding was awesome.
Personally I would look into using graph based data models.
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.
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.
For me this is a workflow problem. CRMs are beasts that live on top of workflows (both formal and informal ones).
If you can can get a good IBPMS for a nice price probably you have a good solution that will be easily customized.
If you can can get a good IBPMS for a nice price probably you have a good solution that will be easily customized.
The best stack is most likely the last one you shipped a finished product with. Every time you double down on that stack you're getting better and faster at using it, code quality improves etc.
My feeling is that no one wants to use CRMs. The best type of CRM is one that autoloads contacts and information from cellphones, email, chat, accounting systems,linkedin etc.
My stack would be: Java or (better) Kotlin, JAX-RS, bean validation, JPA, CDs or Guide, Postgres. I've no clear preference for front-end.
[deleted]
[deleted]
Reach out to me: [email protected]
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.
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.
Vue.js/Weex or Elm, Elixir/Phoenix, Postgres, OpenBSD.
FrontEnd: React, Redux
Backend: KeystoneJS + React, Redux (Universal JS)
Backend: KeystoneJS + React, Redux (Universal JS)
Swift from the metal to the clouds. Everywhere.
Check out golang!
Elm + Postgres.
Elm is for client-side, It needs some backend to talk to postgres. I would use rust or maybe postgrest[0] would do.
[0] https://github.com/begriffs/postgrest
[0] https://github.com/begriffs/postgrest
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.