The rising popularity of APIs as an architectural and development pattern has driven a massive shift in how we think about application and systems design; but how are we thinking about APIs themselves? As API adoption increases, we need to learn how to mitigate risk, maximize utility, and ensure we are building the right APIs for the right people.
Reza Shafii, Director of Product Management, introduces the API Hierarchy of Needs in his InfoQ article, “Minding the API Hierarchy of Needs with RAML and APIkit“, and discusses the advantage of a holistic, broadly inclusive approach to API initiatives.
Mule ESB is a big solution with tons of features. There is information about Mule ESB all around – we have info for our community users as well as our enterprise users – and this info is spread in multiple sources. We know that finding the right information on all of these sources might be a challenge, so we came up with a solution, our new knowledge search engine that we call “Knowledge Center”.
With this search tool you’ll be able to find important information, documentation and how-to guides in one central location. Whether the information is on our enterprise knowledge base, our documentation or within a blog post, you’ll be able to find it in just one place with just one search.
You may have already heard that on December 31st, 2013, Snapchat was hacked and 4.6MM records were subsequently compromised. According to the official blog, “an attacker released a database of partially redacted phone numbers and usernames.” It turns out the hacker(s) had exploited the “Find Friends” API to try to return the username of automatically generated phone number combinations.
In this case, only phone numbers and usernames were released. Pretty harmless, right? Not quite. The most substantial loss that Snapchat faces in this situation is the loss of trust. Snapchat, along with other organizations that have faced similar challenges, will ultimately recover and fix flaws to become stronger than ever before.
This week we’re back with another exciting Meet a Muley post. We chatted with Marina Bottacchi, our Front End Web Developer in Buenos Aires about her geek merchandise days and her adorable pets. As a part of the web and marketing teams, Marina not only ensures our site is always looking good, she does a lot of project management for our more technical web projects.
Keep reading to learn about Marina!
The dreaded user table. Think about it: whenever you start working on a new end-user application, you’ll have to create a table to store emails, user information and passwords. And then you’ll need to add support for the password reset workflow. And so on and so forth. The wheel gets re-invented time and again. Of course, you may go sophisticated and decide to manage users in LDAP or even – gasp – ActiveDirectory. Now you would have a whole different range of problems to deal with, starting with interacting with this external directory in a graceful manner.
Enter Stormpath, the SaaS API whose sole mission is to make authentication and user management awesome and developer friendly! And thanks a new connector for Mule (available here), you can now benefit from Stormpath’s extensive features, which include all of the aforementioned ones, and many more.
In this post, we will look at a Mule application that integrates with the Stormpath API via this new connector. This application exposes a web user interface that uses AJAX to interact with the Mule application. This application allows a user to create an account, log-in and trigger the password forgotten procedure. Enough ado, let’s start digging!
Today I am going to introduce a recently created module: Mule Requester.
As its name may hint, its goal is to allow the request of a resource at any point in a flow. This resource can be a file, a message (from VM, JMS, AMQP, etc.), an e-mail, etc. It’s intended for resources that originally could only be requested by message sources.
Let’s try to explain it better with an example. Say we want to consume messages from a queue on demand, i.e. not consuming the message as soon as it’s put on the queue but at a later stage, when a user calls an HTTP inbound endpoint, for example. We cannot achieve this by using a JMS inbound endpoint, since it will consume the message as soon as it’s put on the queue. Thinking about a way of doing this, we could have a stopped flow and activate it on demand but this would cause the consumption of more than one message or a clumsy implementation that would pick a message and stop the flow again. Another option would be to use a component but this would have to deal with the specifics of the transport, leading to either one implementation per transport type or a big component handling all the transports.
The above mentioned case can be easily achieved using the Mule Requester module, simply by placing the starting point of the flow (the HTTP inbound endpoint in our example) followed by the requester:
Today I will introduce our performance test of the Batch Module introduced on the Mule’s December 2013 release. I will guide you through the test scenario and explain all the data collected.
But first, if you don’t know what batch is, please read the great Batch Blog from our star developer Mariano Gonzalez, and for any other concerns you also have the documentation.
Excited? Great! Now we can start with the details, this performance test was run on a CloudHub’s Double worker, using the default threading profile of 16 threads. We will compare the on-premise vs cloud performance. Henceforth we will talk about HD vs CQS performance. Why? On-Premise and CloudHub users will be using by default the HardDisk for temporal storage and resilience but, this is not very useful on CloudHub as if for any reason the the worker is restarted, the current job will loose all its messages, then if Persistent Queues are enabled the Batch module will automatically store all the data with CQS (Cloud Queue Storage) to achieve the expected resilience.
Skip the hampers and gift cards and give the developers on your team something useful this holiday season to transform their hard-earned skills into something creative.
Way better than Fruitcake, Raspberry Pi is a credit-card-sized single-board computer running Linux that can be used for all kinds of great ideas from running a web server in your pocket to building home automation systems. We used one to fly helicopters using a fitness wristband device at our last MuleSoft hackathon. You can get one here for less than $50.
This week we’re wrapping up our Meet a Muley posts for 2013 with James Hall! As an Interaction Designer on the Product Team, James focuses on creating the best possible experience for our users. Read on to learn why he considers himself a “shaved ice connoisseur” and how he deals with being a tech-neophyte in a tech startup!
First thought that came to mind when you looked into the mirror today?
- Did 6am always feel this early?
How did you find MuleSoft?
- I knew I wanted to relocate to the Bay Area, so I started searching for well funded companies with huge growth trajectories. MuleSoft surfaced through CrunchBase, and I thought the story was very interesting. I really wanted to develop my technical understanding and MuleSoft felt like it would provide a great education.