Here’s what the CEO of Make had to say about this in this thread:
Thank you all for your inputs and allow me to announce that based on your feedback we have developed and introduced a new capability that is called Custom functions.
Custom functions allow you to enhance the built-in data transformation capabilities available in the scenario designer using JavaScript.
Wow, this is an amazing update! And even better implemented then Zapier’s JavaScript functions IMO. Really adds a powerful layer of robustness and just another reason why I choose Make > Zapier
The glue factories are gunning for more than just customers thrilled by custom functions; they want most, if not all, of the no-code market. They stand to become the tail that wags the dog.
By creating massive dependencies by exploiting the sizeable shortcomings of the no-code/low-code platform movement, they will succeed in becoming the biggest lynchpin in the machinery of democratized data management. Some analysts believe this has already happened.
And we thought ransomware was despicable. Free markets can be very efficient at separating you from your cash. Choose wisely who you entrust your data flows to.
I won’t be able to try this out given that it is limited to enterprise. How likely is it that Make is trying out the feature with enterprise before giving access to everyone so that they can get a better idea of the impact on their servers and support staff? Enterprise accounts are also more likely to have access to someone who is capable of writing custom functions.
No renaming of custom functions. This really, really surprises me. At least they are up front about this limitation and don’t bury it. I hate the idea of not being able to rename stuff. Maybe this is to protect people from themselves?
I like the inclusion of a version history. I wish that Airtable had that. I wonder if there is a way to identify the function version in the run history of the scenario. I also wonder if there are ways to compress the history to remove versions for which there are no runs.
I wonder how it will handle functions that uses the spread operator in its parameters in order to take an arbitrary number of inputs. My original guess would be that they would not be allowed.
Some thoughts on limitations:
No HTTP requests and no asynchronous code. This makes sense because Make would rather that people use a no-code modules for these types of requests.
300 milliseconds run time. This makes Airtable’s 30 second run time / 1 second of processing time look really generous.
exactly one return statement. This seems strange to me, but it probably makes things easier for Make behind the scenes so that there is more predictability in the top level shape of the return value, although there are no guarantees. There are also easy workarounds.
No calling other custom functions inside custom functions. That makes reusing code harder, but given that Make probably wants these functions to be relatively short, this probably isn’t an issue. You can have partial workarounds by defining functions inside your function, and then copy/paste when reusing code.
You can not use recursion in your custom functions. I find this surprising. Maybe it is related to the inability to call a custom function from inside a custom function? Maybe they do not trust people to write recursive functions properly? But even if people wrote recursive functions that never ended, wouldn’t the 300 millisecond run time take care of that problem?
That is cool! I have not noticed that module. Interestingly it runs RapidAPI at the back?
I think a separate module for JS would be much powerful than functions - It would be great to be able to run a complete node module with ability to import dependencies just like https://pipedream.com/
Looks can be deceiving. It would only need to run 10x faster than Airtable to maintain parity. Airtable is known (by virtue of its containerized constraints) to run exceedingly slow.
You don’t need 30 seconds to perform a task that under a microservices architecture, takes only 20ms.
Some much cheaper alternatives for writing Javascript code in Make:
Make offers native support for 1Saas, which lets you write JavaScript code within your scenarios — and it lets you do a whole bunch of other cool things, too:
There is also at least one competitor to 1Saas, called CustomJS, that works natively in Make for writing JavaScript code:
This is a great list that you typed up, @Kuovonne!
You might want to consider typing up your comments in the 2 threads below, which might be the only place where Make is monitoring for feedback on these issues.
If you decide to do it, I would probably tag that Ondrej guy in your responses, so he gets an email notification of your comments:
Looks like this new feature wouldn’t have solved anything even if we did have an Enterprise account. Most of the Autocode endpoints that we’ve created to be called from Make are doing both of those forbidden things.
There’s something about this entire approach to taking a data integration layer and embellishing its capabilities with yet another data manipulation layer. The layers seem problematic to me and only serve to increase the angle of the slippery slope you already stepped onto by embracing the glue-factory layer.
I can’t put a finger on precisely the nature of additional risk factors from adding script runners adjacent to a glue factory, but I’d be cautious of approaches that fix the fixer.
Yeah, I love PipeDream and I really am cautious with Make, and this thread only re-enforce this sentiment.
Unrelated, but I’ve always struggled with Make to debug anything, I find their UX to be so poor. While PipeDream just “ticks”. And they have really advanced coding capabilities (and is open source).
