9 ms·

Ask HN: If you were to build a CRM today what would your stack be?

56 points by SnowingXIV 10y ago

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.

danso 10y ago
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 https://github.com/reactjs/react-rails
- lucaspiller 10y ago
  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/ http://www.tiobe.com/tiobe-index/
- deleted 10y ago
  [deleted]
traviswingo 10y ago
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.
jamesmp98 10y ago
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)
- onion2k 10y ago
  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.
  - jamesmp98 10y ago
    First off, we are discussing a CRM not a CMS and secondly, he said no to Rails for perf reasons.
neverminder 10y ago
Angular 2 or React front end, Scala / Play Framework 2 / Postgres backend for some serious scalability.
kyriakos 10y ago
For a CRM the database is probably more important than the programming language / framework.
throwaway2016a 10y ago
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.
- wmichelin 10y ago
  Can you share your rationale for choosing MongoDB?
  - throwaway2016a 10y ago
    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)
    - lotyrin 10y ago
      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.
      - throwaway2016a 10y ago
        :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.
    - tobltobs 10y ago
      > 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?
bronlund 10y ago
Check out golang!
maxxxxx 10y ago
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.
- odonnellryan 10y ago
  Oh? Why do CRMs need customization? In what ways, do you think?
  - bshimmin 10y ago
    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.
  - arethuza 10y ago
    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.
    - odonnellryan 10y ago
      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.
      - maxxxxx 10y ago
        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.
odonnellryan 10y ago
Reach out to me: odonnellryanc@gmail.com 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.
jasonwatkinspdx 10y ago
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.
neeleshs 10y ago
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).
tyre 10y ago
Hi! We're building a CRM for local governments (https://romuluscrm.com 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 http://seneca.systems/careers)
- moflome 10y ago
  +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!
  - arethuza 10y ago
    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.
gorbachev 10y ago
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.
bdcravens 10y ago
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.
- grandalf 10y ago
  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.
  - jamesmccann 10y ago
    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.
    - urlwolf 10y ago
      I would love to know the answer to this too.
      - grandalf 10y ago
        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.
pasta 10y ago
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
- SnowingXIV 10y ago
  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.
jwatte 10y ago
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.
cwyers 10y ago
If you have to ask a question like that, you probably shouldn't be writing your own CRM.
- rightnow 10y ago
  Silly comment
deleted 10y ago
[deleted]
Entangled 10y ago
Swift from the metal to the clouds. Everywhere.
benologist 10y ago
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.
geebee 10y ago
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!
d1ffuz0r 10y ago
I'd recommend you to watch this talk https://www.infoq.com/presentations/SalesForce-Multi-Tenant-Architecture-Craig-Weissman 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
goddamnsteve 10y ago
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 https://allt.in) and UnderstandBetter (https://understandbetter.co/ https://understandbetter.co/)
warpech 10y ago
Shameless plug (I am one of the devs): Starcounter (http://starcounter.com 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.
busterarm 10y ago
Vue.js/Weex or Elm, Elixir/Phoenix, Postgres, OpenBSD.
deleted 10y ago
[deleted]
sachinag 10y ago
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.
- busterarm 10y ago
  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.
merb 10y ago
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.
- ziffusion 10y ago
  What problems did you run into with Angular?
  - merb 10y ago
    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).
k__ 10y ago
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.
anthony_barker 10y ago
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.
patrickgordon 10y ago
I'm building a personal CRM to help me manage my personal relationships (https://simplerm.co 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.
lgas 10y ago
Elm + Postgres.
- ivanceras 10y ago
  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 https://github.com/begriffs/postgrest
eb0la 10y ago
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.
od14 10y ago
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.
- terminalcommand 10y ago
  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.
droidist2 10y ago
FrontEnd: React, Redux Backend: KeystoneJS + React, Redux (Universal JS)
cweagans 10y ago
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.
cryptos 10y ago
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.
ohgh1ieD 10y ago
> 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 https://github.com/johnpapa/angular-styleguide