To app your life, CHOCOLABS takes an API-first approach
CHOCOLABS is one of the largest app publishers in Taiwan with over 50 iOS/Android entertainment focused apps under their belt. We recently spoke with Jerry Weng, one of their co-founders, to talk about building a team, finding a niche, and driving business growth with the right development tools.
Q – Indy | A – Jerry
Q: Who is CHOCOLABS?
A: We are an app publishing company led by three co-founders who met as interns at Microsoft Taiwan. It’s a long story, but we were all in different years, and had different backgrounds—for example Kevin and I both did computer science, whereas our CEO, David, got his masters in business management and worked at a global marketing research firm before we met and decided to form the company.
Financial services information technology (IT) has transformed from order taker to strategic business partner. As part of this transformation, IT organizations are finding they must address key challenges with legacy modernization, data management and digital transformation.
MuleSoft has launched a three-part white paper series discussing these challenges and how financial institutions are overcoming them. In the first installment in our Connected Financial Institution white paper series, we discussed how aging back office systems, operational effectiveness and open source adoption are driving legacy modernization initiatives across the financial services industry. The second installment in the series discusses key data management challenges facing firms including an ever-evolving regulatory compliance landscape, deepening customer relationships with a 360-degree view, and improving data driven decision making.
In spite of JSON’s reign as the king of API data format, XML still remains the exchange data format of choice for a number of systems. Any service exposing functionality through SOAP, and many application built years ago (or even nowadays) still depend on XML to share data – to such an extent that in April 2013 the W3C published a new spec for version 3.0 of the XPath, XSLT and XQuery standards. We decided it was time to update the platform’s support for these standards and fix a couple of things while at it.
If you’re an assiduous reader of this blog, then you probably already heard about our vision around APIs, our Anypoint API Manager solution and all our RAML based stories. Those are our recommended way of approaching REST APIs and if you haven’t already, we all highly recommend you to take a look at them. However, we’re about connecting everything, everywhere. Thus we recognize that there are a lot of APIs out there built in plain old Java code and a migration process is not something you can do overnight. If you own such an API, this post is about us wanting to help you too. Anypoint Platform includes a Jersey module to allow embedding Jersey-based APIs into the runtime, reusing the Java code powering your API but still gaining access to all the other features of the platform. In Mule 3.6 we upgraded our supported Jersey version from 1.6 to v2.11 to give you access to the latest and greatest that Jersey has to offer.
MuleSoft got its start years ago with a great open source project, Mule ESB.
Today we continue to be big believers of open development and that’s why every single line of the community edition source code is publicly available on GitHub.
“Logs are like car insurance. Nobody wants to pay for it, but when something goes wrong everyone wants the best available” - Pablo Kraan
The phrase above fully explains why logs are important and why we need to be able to log as much information as possible without impacting performance. Because logging usually implies an I/O operation, it’s a naturally slow operation.
Before Mule 3.6, logging operations were done using synchronous I/O. This means that the thread processing your message has to wait for the log message to be fully handled before it can continue.
As part of our API-led Anypoint Platform January 2015 launch, I’m pleased to announce the next version of our runtime and tooling, Mule ESB 3.6 and Anypoint Studio January 2015. This release helps users more quickly connect to and design APIs based on a new HTTP connector that adopts a design-first and resource-based approach, all with higher performance. The new release of Anypoint Studio also improves the design experience, upgrades the base Eclipse runtime, and connects to Anypoint Exchange, our expansive library for connector and example information. Finally, major updates to AMQP and our SDLC tooling have been released.
Or jump to part one of the hypermedia sub-series.
A Road Trip
First off, let me apologize for the delay in this third part of the hypermedia sub-series. Christmas meant a warm trip back to Minnesota, a road trip through the Texas panhandle, and numerous snow storms in between — until finally I had the chance to cut through the mountainous desert of Southern California on my way back to beautiful San Francisco.
Now I understand some of you are probably wondering what any of that has to do with this post, other than it’s about 3 weeks after promised. One of the greatest challenges of the drive was battling my way through the snow and construction, and just hoping that the interstate would stay open (they literally close the interstates if it’s bad enough). But the one thing I could be sure of was that at every turn, between my steady GPS and road signs, I knew where I was going, and I knew when my path was being detoured or I couldn’t take a certain road… I knew this, because everything was nice and uniform.
Securing an API in Anypoint Platform is easy. In a previous post we showed how Anypoint Platform for APIs allows you to fully protect your API. We concluded then that the combination of HTTPS and OAuth 2.0 are a rule-of-thumb best practice for Web API security. In this post, we’ll take a deeper dive into the makeup of a security configuration in Anypoint Platform and explore in more detail the areas of Basic Authentication and OAuth2 Authorization in the context of Identity Management. We’ll also give you some pointers about when and how to use these two standards.
Central to authentication in Mule is the Security Manager. This is the bridge between standard mule configuration and Spring Security beans. In the example we build in this blog, we will use Spring Security to authenticate credentials against an LDAP server. We suggest you read the Spring Documentation on this topic if you want to delve further.