User Interface Design · Front end

Recommendation on web front-end development platform

Weihong Zhang Co-founder at Brilent, Inc.

February 5th, 2014

Greetings FDers,

We are researching the development platforms for building a web portal for talent acquisition purpose. The functions include collecting web-form input of user profile info, creating a community forum for sharing questions and answers,  sending/checking internal messages, and logging web activities into a database. Database information retrieval and analytics will be performed in the back-end. 

Some options we are looking at include Java, J2EE, RoR, Python Django, and content management system like WordPress/Drupal. When making the determination, surely the primary consideration is to implement the essential functions above. We prefer to starting with the AWS Linux services. We are considering a fast development cycle but leave rooms for scalability, security, big data and mobile support in future. It appears that Drupal 7 makes the case because it has UI support like View/Panel module, WYSIWYG, user management, database abstract layers, and mobile support. My concern is how to develop an internal message systems, and how it deals with large data set when business scales up. Your thoughts?

Thank you very much in advance.

Will Koffel Co-Founder at Outlearn

February 7th, 2014

Weihong, there's nothing inherent in ActiveRecord or Rails that prevents scale.  It's an architectural question like all other scale issues.  If you are using MySQL for your DB, for example, and you have the right indexes on your data, you are likely quite find up through millions of records.  Once you hit 100M records in a table, other issues will start to crop up, especially if you are regularly changing the schema, or doing large joins against those records.  If you have particular collections of data that need different behavior, than you can explore moving those to some flavor of sharded data-store.

But I'll submit that you are getting ahead of yourself.  These kinds of scaling considerations are almost always premature if you are still at the stage of figuring out which framework to build in.  Ruby, Python, Java, etc. all have paths towards growth that are proven.  None of the modern mature frameworks should prohibit you from building a scalable architecture when the time comes, as long as your team codes smartly against them.

Patrick Hooft Vice President & Director of Operations at Uniglobe Travel British Isles

February 5th, 2014

 Thank you for your e-mail. I'm currently out of the office attending the Business Travel Show and have very limited access to e-mails, and will return on the 6th February 2014. For any urgent matters please e-mail Region@uniglobetravelbi.co.uk or call 0845 257 0332 Patrick

Adam Breen Digital Product Strategist at CPDone Pty Ltd

February 9th, 2014

Hi Weihong,

Do you already have a team? If not, how do you plan to resource this project?

I'll echo comments that steer you away from trying to build this with a CMS. You'll just end up with a bulky half-built system that you need to throw away. Personally, I'd prefer to have my prototype built in the same technologies as I end up releasing with.

Ultimately, the framework doesn't really matter for your purpose - no framework is better than any other at building the sort of business software you describe. Any of the modern web frameworks are more than capable of internet-level scale. If you find yourself hitting issues due to massive scale, you should have enough revenue to deal with those problems as they arise. Typically, up until the truly massive scale level, problems can often be solved by "adding hardware", and other systems patterns, which mitigates much of the early stage risk you seem to be considering.

I asked about your team, because in reality that's your primary issue. If there aren't good RoR people in your location, it's a BAD idea to use that framework (or indeed any framework that you can't easily resource for). You should select the best possible team from what is locally available, unless you are very experienced at managing remote teams. For new products, I highly recommend team colocation.



Weihong Zhang Co-founder at Brilent, Inc.

February 6th, 2014

Thanks, Jesal and Michael. Yes, RoR is a viable option for this. The gems mailboxer and activeadmin are good candidates for internal messaging and CMS. Also, Rails-messaging provides a good GUI interface for messaging applications. One concern about RoR is data base. RoR uses ActiveRecords for storing data cases. I am not sure how it scales up, say, with the number of job seekers (e.g. at 100,000 level), or with the number of communication records whose size grows dynamically if each of which is saved as a BLOB.
 
talentbin appears a great tool in searching the candidates, a big part of the talent acquisition business. Our system has it as one component (we do not expect to have a candidate database at that scale). Our system also includes interactions between candidates and account managers, and between account managers and hiring companies. So an internal messaging system is important, also a discussion forum is nice to have for candidates to share experiences and Q/As.


Jesal Gadhia

February 10th, 2014

In addition to the service Adam mentioned, you can also look into Twilio for adding conference calling capabilities to your application and Google Hangouts API (look at AirPair's integration - http://www.airpair.com/) to add video conferencing. 

Michael Schawel Partner at SCHAWEL+COLES

February 6th, 2014

You mean something like http://www.talentbin.com/ ?

Jesal Gadhia

February 7th, 2014

I second Will's thoughts. I think it's probably too early to worry about scalablity at this point. As long as your team follows best practices and utilize things such as indexing, caching, message queuing, full text search engine, materialized views etc you should be fine with any of the major frameworks out there. 

Adam Breen Digital Product Strategist at CPDone Pty Ltd

February 10th, 2014

Hi again,

If something is possible in drupal, it's possible in any web application. The sort of "live chat" facility you've mentioned is available from a number of different SaaS vendors. http://www.olark.com/ is one that you might want to look at. In most of these cases, you simply embed a small <script> snippet in the page, which loads their software cross-domain.

It sounds to me like you might benefit from documenting your business model, including the high-level product requirements in some way, before you start hiring the team. I'm a fan of Dave McClure's material on "Viagra for VCs": http://vimeo.com/3881271  (even the slides are worth a quick look, if you are short on time).

Best of luck!


Jesal Gadhia

February 5th, 2014

I would suggest looking into using Ruby on Rails and then utilizing https://github.com/ging/mailboxer for internal messaging and http://activeadmin.info/ for CMS. You could probably also build similar functionality with Python/Django.

I would advise against going with an off-the-shelf solutions such as Drupal only because it will put limitations around what you can and can not customize and you'll have to find developers specializing in that particular CMS system. It may be just easier and more cost effective to go for a custom implementation built from ground up to fit your business requirements.

Weihong Zhang Co-founder at Brilent, Inc.

February 10th, 2014

Will, Jesal and Adam, appreciate your added insights. I am assured that it is not a time to worry about the scale issue at this time point. Our engineering effort is behind the business development -- the business is already in operation, and we are developing a web portal to catch up with it -- providing job seekers more content, account managers more convenient tools in talent management and tracking, and interactions among different roles in the process. The level of 100M means a large scale in this application domain, say you have 100M job seeks that is a hard-to-reach number. The scale issue is not important for us, especially for now. Thanks to Jesal for concrete ideas for coping with scale issues including indexing, caching, message queuing, full text search engine, and materialized views etc. After a small-scale product is up, these techniques can help to survive a little longer until the business hits a really big scale obstacle.

As pointed out, drupal is not such a handsome option as it is not a skinny solution, it is hard to find skilled drupal developers, and it is hard to customize a theme once it is selected for current requirements and new requirements come up. But I really love the modules/plug-ins of drupal. For example, the openmeeting plug-in is a nice-to-have feature if we want to have a build-in communication tool with a job-seeker a job seeker needs some advice from us. These interactions can run within the web site, eliminating the need of exiting the web site and jumping to third-party tools like Skype. Hopefully these tools will be available in other web application framework.

We do not have a engineering team yet. We will build one along with the web portal building. The team will take over the built web portal and meanwhile do some back-end analytics from the data collected from the front end.