GitHub Android WeChat Authentication Example

Recently I was tasked with the job of adding login support through WeChat (also known as Weixin). WeChat is a popular social media, mobile phone application based in China. I naively assumed this would be a simple task. Most social media platforms have very well documented SDKs used to query the user for access to their account.

WeChat was unfortunately not so. Very little English documentation is available and any community websites are mostly in Chinese. The SDK API documentation is minimal and doesn't provide much more detail than what could be assumed from reading function signatures. WeChat is based on a messaging system which allows you to send messages to the application. However, if any of the multiple configurations is incorrect, WeChat will never respond leaving you with no indication of what you did wrong.

When looking at the WeChat developer portal, there's two configuration values you need to provide for your android application, a "signature" and package name. Because everything is in Chinese, I had to rely on Google translate. After translation, it wasn't very clear what "signature" to use. After digging through a Chinese forum, I saw reference to MD5. Therefore I filled this field with the MD5 hash of the signature used to sign my application. Package name was easier to guess but there turned out to be some caveats.

Probably the greatest stumbling block in integration with WeChat is its required package structure. The package name I provided in the development portal turned out to be critical to the functionality of WeChat. It turns out your application cannot have an application ID that differs from your package (something that could be an issue). This is because WeChat expects an activity named WXEntryActivity to be placed in a certain location within your app. If your package name is com.demo.wechat, you must place an activity named WXEntryActivity under the package com.demo.wechat.wxapi. You cannot deviate at all from this or WeChat will never respond to your authentication request!

This forced constraint on naming and location was very surprising. None of this could be found on their official site and I only learned of this through lots of testing and digging through Chinese GitHub repositories. After solving the combination of portal and project configuration, the code to request access to a user's WeChat account was simple. After successful authentication, WeChat returns an authorization code which you must hit their rest endpoint with to convert it to an access token.

Don't forget that this all should be done on a real device. WeChat has to be registered and sends a code to a real phone number to do so.

Thoughts, questions, or comments? Feel free to reach out at aaronbruckner@gmail.com.

GitHub link to AWS Lambda tester

Lambda is a powerful tool provided by AWS that teases at the possibility of creating a serverless backend for your applications. Lambda allows developers to upload small modules of code which can be executed on demand. After creating a few simple hello world functions in the browser, a developer could easily start coding large backend projects.

However, such ambition could quickly become their downfall. To understand this, you must first know how AWS executes a Lambda function. AWS runs each function in isolation. When a function is first requested, none of the AWS Lambda nodes have that function cached. A node retrieves the code for the unique Lambda function, executes it, and returns the result. Future executions will now complete faster since one node already has the function loaded. If the function is repeatedly requested, more nodes will pause the request process to load the function.

This pause is hardly noticeable with a 500 byte hello world function and isn't even an issue for most small projects. However, as your project continues to grow, load times will take longer and longer. If the project grows too large, initial load times will increase substantially and users will notice when their applications randomly slow down. As projects balloon, developers will need to find ways to only upload the required code for each Lambda function. This would be manageable for a five function project, but keeping this organized in a 50 function project could get ugly.

While working through this, I wondered how the size of a code package affected function load time. AWS requires you to upload a code package for every function you wish to create. A developer could find ways to isolate individual Lambda functions so that only required code is uploaded. At what point is this a concern?

To test load times, I used a script that created fresh functions at a variety of code sizes, executed them once to see initialization time, and then deleted them. I repeated this process to get multiple measurements per code size. The code sizes used were: 665 bytes, 550 KB, 1.6 MB, 3.2 MB, 27.4 MB, 48 MB, and 68.3 MB. To reach these sizes, I found popular node modules, installed, and imported them into the function under test. All functions were executed in the nodejs environment. The results below include transit time over the network to make the request to AWS Lambda.

Unsurprisingly, function initialization time and the size of the function shared a linear relationship. Developers should be mindful of including needless libraries of excessive size. A project would have to reach substantial size to impact unlucky users. Code sizes of 25 MB compressed started to reach unacceptable load times approaching four seconds. It would be unfortunate to hit this performance wall with a large project unaware of the load constraint. Project structuring would help to minimize this issue. Ideally a function's upload to AWS should only contain lines of code used by it. Anything extra is technically waste. This could involve clever build packaging to produce minimal Lambda functions that still share code locally within a project.

Thoughts, questions, or comments? Feel free to reach out at aaronbruckner@gmail.com.