“It was the best of times, it was the worst of times”. While the opening for one of Dickens’ famous novels might not have been about programming, it does describe the process of understanding synchronous and asynchronous programming quite well. A lot of interns and new GeoDevs get thrown off by these concepts, so we thought we’d put together a high-level primer to serve as a foundation for anyone trying to break it down.
What do ‘Synchronous’ and ‘Asynchronous’ mean?
In terms of development, synchronous means everything happens step-by-step, in order. Each step is fully complete before moving onto the next one. Most developers learn to write synchronous code first. You’re reading this article synchronously right now (unless you can magically read multiple parts of it at the same time. In that case, please get in touch.)
Asynchronous, on the other hand, allows for code to happen out-of-order. Something may be half-done while something else kicks off, and both are happening at the same time. This is often a little harder for new developers to wrap their heads around. Once they do, however, a whole new world of opportunities await them. As with any new tool, learning how to leverage asynchronous programming properly allows a developer to craft a wider array of new, and potentially more powerful, solutions.
Perhaps, in your code, you will get to a point where a method is called. If the code jumps to that method, completes it step-by-step, then returns to the point where that function was called, it’s still synchronous. It’s synchronous because the code that called the method pauses and waits until the method finishes before continuing.
To keep with our conversation analogy, it’s as if you were chatting with your friend when they remembered they wanted to show you something. They got up to grab the item, and the conversation paused while they fetched it, then resumed when they returned.
Imagine you are planning on a trip across a continent. At each stop, you will send your friend a letter. When your friend gets them, they will e-mail you back. When you start your journey, you go to each of your planned stops in order, but you soon notice the e-mails your friend is sending appear to be replying to the letters out of order. You realize, because different places have different processes and policies for handling post, your friend isn’t getting the letters in order. This is fine, as you and your friend both have enough information (the location the letter was sent from, events described, etc.) to know what you’re both talking about.
How do I know which one to use?
Sometimes, a bit of critical thinking can help you figure it out. For example, if you have 1,000 polygons, and you need to buffer all of them, generate a graphic for each one, then add them to a map, do you really need to wait for each step to finish for all of them before continuing? Not really. You can invoke a geoprocessing service to buffer the polygons. Some will be easier to buffer than others (small polygons with a few vertices in a single ring, as opposed to a large polygon with several rings and lots of vertices). When a polygon is buffered, you can generate its graphic for the map. When all the graphics are finished, just add them to the map. This allows you to be more efficient and will reduce the wait-time of any user interacting with your application.
Want to hear more from GEO Jobe?